Method for adapting the sizing of a virtualization infrastructure to a service load.

Abstract

Method for adapting the sizing of a virtualization infrastructure to a service load. The invention 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 N virtualization units absorbing said service load in a nominal mode, there are B backup virtualization units to guarantee absorption of said service load in the event of failure of at most B virtualization units.According to this process, a decision to add or remove a virtualization unit (UV) from a set of virtualization units instantiated for the implementation of said service is made based on: - 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 allowed per virtualization unit (UV) in said set. Abbreviated figure: Figure 4.

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 allowing 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 Au-toscaling”, which makes it possible to automatically adapt the number of virtualization units installed on all 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 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 “Kubernetes®” architecture, allowing the implementation of such a mechanism.

[0008] As described previously, in such an architecture, a number R (called “Replicas”) of virtualization units UV is deployed on one or more virtualization nodes, for the implementation of a service.

[0009] A probe module Mod_S 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 bounded between a predefined lower limit "MINPODS" and an upper limit "MAXPODS".

[0012] A load distribution module Mod_LB distributes the SL service load across all R available virtualization units. By way of illustration and non-limiting example, this SL service load can be defined as a number of service requests per second, in which case the Mod_LB load distribution module relays a portion 1 / R 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 sent by the virtualization units, in which case the Mod_LB load distribution module relays the service requests to each of the R virtualization units so that the rate of Internet packets sent by each of the virtualization units approaches the ratio 1 / R of the total rate of Internet packets sent 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:

[0014] yK(k\imSe \ R\k+ 1J — Ceil target»requests 1(1) /

[0015] with

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

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

[0018] - usagep the CPU usage measured by the probe module for the virtualization unitp between time k and time k+1;

[0019] - ceil the rounding up function;

[0020] - and the additional constraints, not formalized in equation (1) but put 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.requesls, 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 yes" 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 that "Kubernetes®" takes to reinstantiate an alternative virtualization unit to the faulty unit. Several causes can delay the instantiation of an alternative unit.The choice of virtualization node may be delayed, for example, due to 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 due to network overload, etc.

[0023] A conventional solution to this problem consists of adopting a protection scheme according to which for N virtualization units necessary 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 the example of a 4:1 protection scheme. 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 failing in the least favorable situation, i.e. when only two virtualization units are deployed, the still functional virtualization unit remains able to absorb the entire service load previously distributed over the two units. MAXPODS is furthermore 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 failing.

[0025] The protection mechanism described above is therefore effective in that it makes it possible to prevent the system from being punctually 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 crucial 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 more recent computer servers, the heterogeneous performances do not make it possible to guarantee that the B virtualization units distributed on computer servers of different performance than the computer servers on which the N nominal virtualization units are hosted can compensate for the failure of B units among the N nominal virtualization units.

[0030] The object of the present invention is to resolve all or part of the drawbacks previously cited. 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 in fact 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 N virtualization units absorbing said

[0032]

[0033]

[0034]

[0035]

[0036]

[0037]

[0038]

[0039]

[0040]

[0041]

[0042] 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: - 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 of said set. 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. In a particular embodiment, said decision to add or remove a virtualization unit is governed by the formula: if with - B(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; - PLp the service load reached at the level of a virtualization unit p of said set between time k and time k+1, called current service load. In this way, the triggers of scale yes 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. 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 manner, without major modifications to the scaling module of a “Kubernetes®” architecture, a service load being able to 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 a “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, a simple means is available, 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 capacities of different virtualization nodes and the obtaining of normalized processing capacities 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] - of the number B of backup virtualization unit defined in said scheme of protection;

[0055] - of a comparison between a total service load reached SL and a load of maximum service 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 one 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 for adapting the sizing of a virtualization infrastructure to a service load, as described previously in any of its embodiments, when executed on a computer.

[0058] The proposed technique also aims at a recording medium readable by a gold 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 comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a USB key 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 it contains is remotely executable. The program according to the invention may in particular be downloaded over a network, for example the Internet.

[0061] The different embodiments mentioned above can be combined with each other for implementing 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 “Kubernetes®” architecture without a protection scheme, according to the prior art;

[0065] [[Fig.3] illustrates an example of the effects of implementing an updating mechanism the horizontal scale within a “Kubernetes®” architecture implementing a protection scheme, according to the prior art;

[0066] [Fig.4] schematically presents the different modules of a modified “Kubemetes®” architecture, 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 in the event of a large 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 “Kubernetes®” 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 “Kubernetes®” 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 a modified “Kubernetes®” architecture, 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 makes it possible to overcome some of the aforementioned drawbacks.

[0074] In all the figures of 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 “Kubernetes®” architecture implementing an N:B protection scheme, aimed at improving its energy performance.

[0076] A “Kubernetes®” architecture modified according to the present technique is presented schematically in relation to [Fig.4].

[0077] Compared to the classic “Kubernetes®” 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 plan implemented;

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

[0080] More particularly, the implementation of these modifications requires several

[0081]

[0082]

[0083]

[0084]

[0085]

[0086]

[0087]

[0088]

[0089] joint adaptations of the “Kubemetes®” architecture, illustrated in [Fig.4] in a particular embodiment of the proposed technique and presented below. 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. 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 PLp service load reached at the level of the virtualization units. According to a third adaptation, a new reference threshold value PLmax is provided as input to the scaling module, corresponding to a maximum service load tolerated per virtualization unit, this new threshold value PLmax replacing the threshold value “targets.requests” - i.e. the percentage of the CPU load reserved by Pod - used in the classic “Kubemetes®” architecture of the prior art. According to a particular characteristic, 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. According to another particular characteristic, alternatively, the maximum admissible service load PLmax 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 of a service request on the virtualization unit(s) considered. The new formula for calculating the threshold for triggering a scaling operation consists of calculating the sum of the service loads of each virtualization unit and dividing it by the maximum service load PLmax accepted per virtualization unit, rounding the result up to the next whole number, and adding the quantity B of virtualization units provided for in the targeted protection scheme, according to the following formula: / Yr^pl \ (2) ■ i ■ f With : - 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 + 1, subsequent to said instant k;

[0091] - ceil the rounding up function;

[0092] - and the additional constraints, not formalized in equation (2) but always implemented, whereby 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 modifications to the scaling module of a “Kubemetes®” architecture, since a service load can be reported in a format close to a CPU load.

[0095] Secondly, it makes it possible to make scaling decisions - i.e. the triggering of 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" in all 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 in a non-linear manner relative 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 virtua unit lization occurs too early compared to the nominal time in terms of energy efficiency;

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

[0099] Due to these two phenomena, the energy efficiency of the horizontal scaling mechanism deteriorates, and this is all the more so when the empty load is high.

[0100] The combination of the two main modifications of a “Ku- bemetes® » as proposed according to the general principle of the present technique - i.e. taking into account the number of backup virtualization units on the one hand, and the use of the service load rather than the CPU load on the other hand, as decision criteria for 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 SL _ pl nya No hysteresis effect and the previously described undesirable phenomena do not occur with the proposed technique, even in the case of a significant 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 integer level), thus ensuring optimal energy efficiency, equivalent to the best energy efficiency that can be obtained with regard to the triggering 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 will subsequently focus, in a complementary manner, on 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 buy identical equipment in large quantities than to buy equipment with varied technical characteristics in addition small quantities).

[0105] In certain situations, however, it happens 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 sellers of these computer servers). In any event, such situations are likely to be more and more frequent, in a global context of imperative resource savings where the 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 an 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 “Kubernetes®” 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 that can be reserved per unit of time.

[0109] In a preliminary step 71, during its enrollment within a cluster (or "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 the previously described figures 1 and 4, its operation and its interactions with the other modules not being modified in the previously described embodiments). Before any reservation of processing time on the node i, this total capacity "total_CPU_i" CPU processing capacity corresponds to an available processing capacity “AvailablejCPU_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 installation module Mod_INS 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 (“daughter ring”) 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 “AvailablejCPUJ” 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 the instantiation of 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], we consider that node i is thus chosen, and the orchestration module Mod_ORC ​​therefore removes the quantity “requests” from the processing capacity available 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 Ni 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 for defining the parameter PLmax to be provided as input to the update module. the scale (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.

[0115] Additional modifications to the “Kubernetes®” 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 particularly, [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.

[0118] First, 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.

[0119] In a preliminary step 81, during the enrollment step 71 of [Fig.7], each virtualization node (for example the virtualization node i “Node_i” illustrated 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" to the available processing capacity within the different virtualization nodes (for example "AvailablejCPU_i" for node i), but to an available processing capacity normalized according to a ratio between the operating frequency of the node considered and the reference clock frequency, i.e. "availablejCPU_i * (Clk_i / Clk_ref)" 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], it is considered that the 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 following 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_ref)” always remains available for this virtualization unit.

[0124] In other words, at each step, a normalization of the operations carried out 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 normalization principle described in relation to [Fig.9] is also applied in the context of a scale in operation, when it is a question of determining on which virtualization node to remove a virtualization unit.

[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] - of the number B of backup virtualization unit defined in said scheme of protection;

[0130] - of a comparison between a total service load reached SL and a load of maximum service 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 qP, 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 various modules previously described, so as to optimize the energy performance of a “Ku-bemetes®” 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 unit processing unit 12. For the implementation of the operations carried out by a scaling module, 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 at 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 “Ku-bemetes®” 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. Method according to claim 1, characterized in that said decision to add or remove a virtualization unit is governed by the formula: iy pi \ R(k+l)=ceid +B with - R(k) the number of virtualization units instantiated at a time k; - R(k+1) the number of virtualization units to be instantiated at a time k + 1, subsequent to said time k; - PLp the service load reached at the level of a virtualization unit p of said set between time k and time k+1, called current service load.

3. Method according to claim 1, characterized in that 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.

4. Method according to claim 1, characterized in that said maximum service load PLmœi authorized 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 making it possible to guarantee 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 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.

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