Method for optimizing the dimensioning of a virtualization infrastructure to a service load

Abstract

The invention relates to a method for optimizing the dimensioning of a virtualization infrastructure to a load of a communication service. The method is implemented by a pre-deployment entity (EPD) and comprises, prior to an increase (AC) of said load of the communication service, a phase of partially configuring (PI) at least one server of a group of reserve servers, referred to as the pre-deployment phase, comprising transmitting, to a deployment entity (ED), a request to install, on said at least one server, an operating system and at least one component of a solution for automated deployment of containerized applications assessed as being suitable for implementing the communication service.

Description

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

[0001] The invention lies in the field of load distribution across a set of computing resources. More particularly, the present invention relates to 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, 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 "Kubernetesmasternode", and a plurality of computing nodes, or "Kubernetesworkernode" 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 software components. A software component, when executed, contributes to the implementation of a virtualized service or function.

[0006] The ETCD database embedded in the management node stores in reference files a list of virtualization units to be instantiated as well as parameters to be taken into account when instantiating a service or virtualized functions.

[0007] The management node regularly reads the contents of these files, compares them with the virtualization units being instantiated and adds or removes virtualization units in order to adapt their quantity to that indicated in these reference files.

[0008] Since the ETCD database is also accessible by a virtualization node deployment entity, the latter regularly reads the contents of these files, compares the capacity of the deployed virtualization nodes with the capacity required by the virtualization units being instantiated and adds or removes virtualization nodes in order to adapt their quantity to needs.

[0009] A Kubernetes architecture integrates various load distribution mechanisms, including so-called horizontal scaling mechanisms that allow the number of resources (for example, the number of virtualization nodes, or the number of virtualization units installed on all the 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 the system must be able to absorb in order to guarantee satisfactory quality of the service provided. Thus, in response to an increase in load, for example, a larger number of virtualization nodes can be deployed.Deploying a new cluster of virtualization nodes (or "cluster") on a computer server, however, requires numerous preliminary configuration operations for this server which, although automated, take time. These operations, orchestrated by a deployment entity, include, for example, the installation of an operating system adapted to the context of implementation of the service, the installation of computer libraries, the installation of Kubernetes components, the installation of additional software components that may be necessary, etc.Thus, when they involve the configuration of a new server, it is estimated that fifteen to twenty minutes are currently required between the moment when a decision is made to increase the number of resources allocated to a service to cope with an increase in load, and the moment when the additional resources requested are actually operational to contribute to the implementation of the service.

[0010] During this deployment time, the service is likely to be degraded to the extent that the minimum resource conditions to ensure normal operation of the service are no longer met. Furthermore, for certain critical applications for which a simple slowdown of the service is sometimes likely to have significant undesirable consequences, particularly when user security depends on the proper operation of the service, such a deployment time is often prohibitive.

[0011] A classic solution to this problem is to oversize the system, by providing and continuously maintaining active a number of resources greater than those necessary to absorb an average or high service load of the service, so that the system is able to cope without delay with a more or less prolonged temporary increase in load, without the need to configure new servers.

[0012] However, such a solution is not ideal. On the one hand, it continuously mobilizes IT resources, typically servers, and this in a sterile manner most of the time, since these "reserve" resources are only requested during specific periods of increased load. As a result, although not used most of the time, these resources cannot be made available to other services that might need them. On the other hand, such oversizing of the system has impacts in terms of energy consumption, with in particular an increase in electricity consumption.

[0013] At a time when the challenges of saving resources – both energy and material – have become critical, there is therefore a need for alternative solutions to resolve all or part of the drawbacks mentioned above.

[0014] 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 optimizing the sizing of a virtualization infrastructure to a load of a communication service. According to the general principle of the proposed invention, such a method, implemented within a pre-deployment entity comprises, upstream of an increase in said load of the communication service, a phase of partial configuration of at least one server of a group of reserve servers, called pre-deployment phase, comprising the transmission to a deployment entity of a request for installation, on said at least one server, of an operating system and at least one component of an automated deployment solution for containerized applications deemed suitable for the implementation of said communication service.

[0015] In this way, the pre-deployment phase makes it possible to carry out in advance, that is to say before a possible need for an increase in the communication service load, operations known to be time-consuming when it comes to configuring servers, namely the installation of an operating system and an automated deployment solution for containerized applications. In this way, the scaling time in response to a possible subsequent detection of an increase in load for the service in question is reduced to that required to carry out operations aimed at completing a configuration that has already been carried out for the most part. The reaction time of the system to return to nominal operation following such an increase in load is therefore considerably reduced.Furthermore, the servers partially configured in the pre-deployment phase are not specifically attached to a particular communication service: since their configuration is not finalized at this stage, they constitute so-called reserve resources, which are likely to be used indifferently by different services, depending on the load requirements and technical characteristics associated with these services. In this way, it is possible to avoid attaching resources full-time to a specific service, even though there is a high probability that such resources will only be used occasionally by said service. The method therefore makes it possible, in addition to faster adaptation of a virtualized infrastructure to a scaling up of one or more communication services, to be able to adjust the virtualized infrastructure to the needs, preserving communication, software and energy resources.

[0016] In a particular embodiment, said at least one component belongs to the group comprising:

[0017] - a utility;

[0018] - a computer library;

[0019] - a configuration file;

[0020] - an artificial intelligence engine;

[0021] - an elementary component of said communication service.

[0022] In this way, the partial configuration operations of said at least one server can relate to various and multiple components. Thus, a large number of components can be pre-configured, in a flexible manner, within the framework of a pre-deployment phase according to the present technique, thereby reducing the time required to finalize their configuration in the event of possible detection of an increase in the load of the communication service.

[0023] In a particular embodiment, said pre-deployment phase is implemented on the basis of a declarative type file previously obtained by said pre-deployment entity.

[0024] In this way, the pre-deployment phase is particularly simple to implement for a service operator, since it is sufficient to declare within a simple file, via key-value type entries, the characteristics of the partial configurations that it wishes to see deployed. In this way, the pre-deployment phase can also be triggered at the initiative of a third-party IT system adapted to automatically generate such a declarative file.

[0025] According to a particular characteristic, said declarative file includes at least:

[0026] - a type and version of said operating system to be installed on said at least one server;

[0027] - a type and version of said automated containerized application deployment solution to be installed on said at least one server;

[0028] - a number of servers to be partially configured within said reserve server group, for said types and versions of said operating system and said automated containerized application deployment solution.

[0029] In this way, the proposed technique allows to pre-deploy different types of partial configuration, each associated with a particular operating system and / or a particular automated deployment solution of containerized applications, on a chosen predefined number of servers. In this way, it is possible to implement several pre-deployment strategies, each in relation to a different subgroup of a group of reserve servers, thus allowing the method according to the present technique to be particularly adapted and flexible to respond to a large number of situations, in particular in terms of diversity of communication service to be supported.

[0030] In a particular embodiment, said sending of an installation request is conditional on a prior verification, with an authorization management server:

[0031] - that said deployment entity is authorized to carry out said installation as part of said pre-deployment phase; and / or

[0032] - that said at least one server of said reserve server group is authorized to be the subject of said installation within the framework of said pre-deployment phase.

[0033] In this way, checks are carried out before carrying out a pre-deployment, in order to protect against any untimely pre-deployment such as, for example, a pre-deployment on a server which would not be intended for such operations or pre-deploying too many servers for example.

[0034] In a particular embodiment, said pre-deployment phase comprises:

[0035] - obtaining, within a data structure associated with said group of reserve servers, at least one item of data identifying a set of servers available for the implementation of said communication service, within said group of reserve servers;

[0036] - the selection, within said identified available servers, of said at least one server which is the subject of said installation request, based on the content of said declarative type file and technical characteristics associated with said available servers, obtained in said data structure.

[0037] In this way, checks are carried out to ensure that a reserve server selected to be the subject of a partial configuration defined in a declaration file is indeed available and has sufficient technical characteristics for such an operation.

[0038] According to a particular characteristic, said issuing of an installation request comprises the uploading, within a version management system associated with said deployment entity, of at least one deployment file comprising partial configuration information of said at least one selected server, said at least one deployment file being generated according to the content of said declarative file and said technical characteristics associated with said at least one selected server.

[0039] In this way, classic mechanisms close to those implemented in the context of a complete server configuration, including the uploading of configuration files in a version control system associated with a deployment entity, are used to carry out partial configuration operations of the selected servers. The implementation of these operations is thus simplified.

[0040] In a particular embodiment, said method comprises, in response to an increase in load of said communication service:

[0041] - the selection, from among said at least one server partially configured in said pre-deployment phase, of at least one server whose partial configuration is compatible with a deployment request descriptive file obtained by said pre-deployment entity following detection of said increase in load;

[0042] - finalizing the configuration of said at least one selected partially configured server, delivering an operational server for the implementation of said communication service.

[0043] In this way, the time between the moment a decision is made to increase the number of resources allocated to a service to cope with an increase in load and the moment when the additional resources requested are actually operational to contribute to the implementation of the service is substantially reduced.

[0044] In a particular embodiment, a determination of the compatibility of said partial configuration with said deployment request descriptive file comprises a verification that the operating system and the at least one component of an automated containerized application deployment solution installed on said at least one selected partially configured server are compatible with the implementation of said communication service.

[0045] In a particular embodiment, said selection of said at least one server comprises taking into account a location of said at least one server, with regard to at least one location information included in said deployment request descriptive file, determined according to a nature of said communication service.

[0046] In this way, characteristics specific to the communication service facing an increase in load, such as its nature or technical characteristics associated with this service, are taken into consideration for the selection and final configuration of the reserve servers to be assigned to said service to help absorb said increase in load.

[0047] In a particular embodiment, said finalization of the configuration is conditional on a prior verification, with an authorization management server, that said at least one selected partially configured server is authorized to be the subject of said configuration finalization.

[0048] In a particular embodiment, said finalization of the configuration is conditioned on a prior verification, within a data structure associated with said group of reserve servers, that said at least one selected partially configured server is available for the implementation of said communication service.

[0049] In this way, checks are carried out before finalizing the configuration of a selected reserve server, in order to ensure that this server is still available and still authorized to be the subject of such an operation. Any possible change in availability and / or authorization occurring after the partial configuration operations of this server in the pre-deployment phase can thus be detected and taken into account.

[0050] In a particular embodiment, said finalization of the configuration comprises:

[0051] - generating, on the basis of said deployment request descriptive file, at least one configuration information of said at least one selected partially configured server;

[0052] - configuring, on said at least one partially configured server selected, on the basis of said at least one configuration information, at least one virtualization node according to said automated containerized application deployment solution, for the implementation of said communication service.

[0053] In this way, additional resources suitable to help absorb the load of the communications service are available and operational.

[0054] According to another aspect, the invention relates to a pre-deployment entity for optimizing the sizing of a virtualization infrastructure to a load of a communication service. Such an entity comprises means for partially configuring at least one server of a group of reserve servers, called pre-deployment means, implemented upstream of an increase in said load of the communication service, said pre-deployment means comprising means for transmitting, to a deployment entity, a request for installation, on said at least one server, of an operating system and at least one component of an automated deployment solution for containerized applications deemed suitable for the implementation of said communication service.

[0055] Such an entity can of course have the different characteristics relating to the optimization method according to the invention, which can be combined or considered in isolation. Thus, the characteristics and advantages of this entity are the same as those of the optimization method, and are not detailed further.

[0056] According to another aspect, the proposed invention 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 the method as described above in any of its embodiments, when this method is executed on a computer.

[0057] The proposed invention also relates to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing the steps of the method as described above, in any of their embodiments.

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

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

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

[0061] 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:

[0062] schematically presents the main steps of a method for optimizing the sizing of a virtualization infrastructure to a service load, in a particular embodiment of the proposed technique;

[0063] presents a sequence diagram illustrating a first phase, called pre-deployment also called partial deployment, of the optimization process, in a particular embodiment of the proposed technique;

[0064] presents an example of the contents of a declarative file of pre-deployment configurations to be operated, in a particular embodiment of the proposed technique;

[0065] presents a sequence diagram illustrating a second phase, called deployment finalization, of the optimization process, in a particular embodiment of the proposed technique;

[0066] describes a simplified architecture of a pre-deployment module of a pre-deployment entity for implementing the proposed technique, in a particular embodiment of the proposed technique. Detailed description of the invention General principle

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

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

[0069] According to a first aspect, the present technique relates to a method for optimizing the sizing of a virtualization infrastructure to a load of a communication service, implemented by a pre-deployment entity. The proposed technique relates more particularly to techniques for optimizing the horizontal autoscaling time of an automated deployment solution for containerized applications such as Kubernetes for example.

[0070] The general principle of the proposed technique, illustrated in relation to a particular embodiment, consists of partially and anticipatedly configuring at least one reserve server prior to a need for AC load scaling of a communication service, i.e. in an upstream phase of the moments when a service load is likely to increase (for example, before the communication service is put into operation, or when the current infrastructure deployed for the implementation of the communication service is still capable of absorbing an observed service load). More particularly, such a partial configuration phase, also called pre-deployment phase P1 in the context of the present technique, comprises the installation, on one or more reserve servers, of an operating system and at least one component of an automated deployment solution for containerized applications.The communication service may be a value-added service, i.e. a voice, text, or video service intended for one or more customers of the communication service, or it may also be a service specific to a communication operator, for example a communication service of a control or administration plan of a communication network. The scalability required for the communication service may correspond to a need for access by a larger number of terminals to the communication service or even to greater functional richness of the communication service requiring longer processing times for the management of data relating to the communication service.

[0071] A communication service that can more particularly benefit from the optimization process concerns, for example, a network game where it appears very important on the one hand to adapt the infrastructure to the geographical diversity of the players accessing the game as well as to the increase in load induced by a number of players connecting simultaneously to the network game. Knowing that low latency is a crucial issue for the players accessing this communication service and that it is very important to respond very dynamically and very quickly to the requirements of increase in load induced by a potentially significant growth in the number of players in a fairly short period of time, the process advantageously makes it possible to reduce the increase in load time of the infrastructure and thus to meet the requirements of the users.The method is particularly suitable for the future implementation of gaming applications accessible via streaming technology in CDN (Content Delivery Networks) nodes such as those specified by the SVTA (Streaming Video Technology Alliance) Open Caching organization and the IETF CDNi (Content Delivery Networks Interconnection) working group.

[0072] In a particular embodiment, the operating system and the components of an automated deployment solution for containerized applications thus installed on a reserve server during the pre-deployment phase P1 correspond to software elements whose probability of being compatible with communication services already deployed or to be deployed on a communication network is high.

[0073] In other words, it is proposed according to the present technique to operate a two-stage configuration of the servers which are potentially to be used to contribute to absorbing a one-off increase in load of a communication service:

[0074] - initially, a partial configuration P1 is carried out in anticipation, i.e. even before such an increase in load is observed, so the duration of such a pre-deployment phase is not a critical factor;

[0075] - in a second step, and only when the situation requires it, i.e. for example in the face of a sudden increase in AC load, a P2 finalization of the configuration, so as to make the server operational as quickly as possible to contribute to the absorption of the observed load.

[0076] More particularly, thanks to the present technique, the scaling time in response to an increase in AC load is reduced to that necessary to carry out operations aimed at completing a configuration already well advanced in a second phase P2 called configuration finalization, the most time-consuming configuration operations (for example the installation of an operating system) having already been carried out upstream in the pre-deployment phase P1.Typically, with the proposed technique, less than three minutes (one to two minutes in most cases) elapse between the time a decision is made to increase the number of resources assigned to a service to cope with an increase in load, and the time the requested additional resources are actually operational to contribute to the implementation of the service (compared to ten to fifteen minutes with the existing conventional scaling mechanism presented in relation to the prior art).

[0077] In addition to this substantial gain in reaction time, the present technique also makes it possible not to continuously mobilize servers as backup servers associated with a single service, unlike the conventional system oversizing solution already described in relation to the prior art. Indeed, the servers partially configured in the pre-deployment phase P1 according to the present technique are not dedicated to the implementation of a single predefined service. On the contrary, they belong more particularly to a group of so-called reserve servers, which constitute resources that are likely to be used indifferently by different services, depending on the needs. In other words, a reserve server S1 can be assigned to a service A during a temporary period of increased load of this service A, then later assigned to a service B during a temporary period of increased load of service B. Presentation of a particular embodiment

[0078] In the remainder of the document, the pre-deployment P1 and deployment finalization P2 phases are described in more detail, in various particular embodiments of the proposed technique, in which the deployment of the service is implemented via a Kubernetes orchestration solution (it being understood that the general principle presented previously and the steps described below remain substantially the same for the deployment of services via automated deployment solutions for containerized applications other than Kubernetes).

[0079] This is a sequence diagram illustrating the implementation of a pre-deployment phase P1, in a particular embodiment. Such a pre-deployment phase is implemented at a pre-deployment entity EPD.

[0080] In a step 201, an administrator, possibly via an administration software system, expresses his wish to authorize a deployment entity ED to carry out pre-configuration operations of one or more servers, i.e. pre-deployment, according to the present technique. To this end, he transmits during this step 201 to an authorization management server SGH of the pre-deployment entity EP an indication to this effect, and receives in return, in a step 202, a confirmation that the deployment entity ED is now identified within the authorization management server SGH as authorized to carry out pre-deployment operations. Such a deployment entity ED corresponds for example to an entity capable of configuring servers, including an integral configuration as described in relation to the prior art.

[0081] In a step 203, the administrator also communicates to the SGH authorization management server identifiers of servers or types of servers that it wishes to authorize to be pre-deployed, for example according to the geographical area where they are located. For example, the administrator transmits to the SGH authorization management server one or more identifiers of particular servers, or information according to which it wishes to authorize pre-deployment for servers located in particular data spaces, such as SV_RC servers located in regional data spaces (“Regional Clouds” in English), SV_EC servers located in end data spaces (“Edge Clouds” in English), or SV_FEC servers located in border data spaces (“Far Edge Clouds” in English), such spaces being in particular defined by the O-RAN alliance (“Open Radio Access Network” in English).The administrator receives in return, in a step 204, a confirmation that the chosen servers or types of servers are now correctly identified within the SGH authorization management server as authorized to be the subject of pre-deployment operations according to the present technique.

[0082] In the particular embodiment illustrated in, the pre-deployment is initiated following the upload, in a step 205, of a declarative FD type file within a pre-deployment module MPD (for example implemented in the form of a Kubernetes operator) of the pre-deployment entity EPD. The declarative FD file contains information useful for the pre-deployment to be carried out, relating in particular to the operating system and the components of the deployment solution to be deployed on one or more reserve servers. An example of an extract of the content of such a declarative FD file is illustrated in relation to the. More particularly, the FD file lists one or more pre-deployment operations to be implemented, each associated with a type and version of operating system 31 and deployment solution 32 to be installed, a deployment entity 33 to be used to perform the pre-deployment, and a number 34 of standby servers to be pre-deployed.In the example of the, are thus defined for example:.

[0083] - a first reference pre-deployment request name_deployment_1, according to which a deployment entity kanod_name_1 is asked to pre-deploy ten servers by installing the Ubuntu operating system version 23.04 and the necessary components of the Kubernetes deployment solution version 1.15;

[0084] - a second pre-deployment request with reference name_deployment_2, according to which a deployment entity kanod_name_2 is asked to pre-deploy five servers by installing the Debian operating system version 12.4 and the necessary components of the Kubernetes deployment solution version 1.10.

[0085] The declarative file presented is given for purely illustrative and non-limiting purposes. In particular, additional information other than that listed above may be declared in connection with a given pre-deployment request. Such additional information includes, for example, information relating to different types of components to be installed in connection with an automated containerized application deployment solution declared in the FD declarative file, such as information relating to the installation of utilities, specific software libraries, artificial intelligence engines, specific configuration files, elementary components associated with the communication service, etc.

[0086] Upon detection of the presence of such a FD declarative file, various mechanisms are triggered at the level of the MPD pre-deployment module of the EPD pre-deployment entity, as illustrated in the.

[0087] Firstly, the pre-deployment module MPD queries the SGH authorization management server in a step 206, in order to verify that the deployment entity associated with a pre-deployment operation in the declarative file FD, for example the deployment entity ED of the, is indeed authorized to carry out pre-deployment operations. If this is the case, the pre-deployment module MPD obtains confirmation of this authorization from the SGH authorization management server, in a step 207. The pre-deployment module MPD then issues, in a step 208, a request to a BDD data structure of the EPD pre-deployment entity, which contains information relating to the servers of a group of reserve servers that can be used for implementing communication services.At least part of this information may in particular have been inserted into the BDD data structure jointly with step 203 previously described, in which servers are authorized to be subject to a partial configuration according to the present technique. The request issued in step 208 aims more particularly to determine a list of servers currently available for the provision of a communication service. In a step 209, in response to this request, the BDD data structure transmits to the pre-deployment module MPD such a list of available servers (for example in the form of data making it possible to identify these servers, for example IP addresses or any other identifier such as for example a DNS identifier), as well as associated information, typically technical characteristics linked to these servers.

[0088] In a step 210, based on the configuration information declared in the declarative file FD obtained in step 205 and possibly additional information associated with the available servers identified in step 209, the MPD pre-deployment module selects from among these available servers those which must be the subject of a pre-deployment, in other words a partial configuration according to the present technique. For example, with reference to the example of the, in the context of the pre-deployment request referenced name_deployment_1, the MPD pre-deployment module selects ten servers from among the available servers of the reserve server group, which have technical characteristics compatible with the configuration information declared in the declarative file FD, typically technical characteristics sufficient to install the Ubuntu operating system version 23.04 and the Kubernetes deployment solution version 1.15.

[0089] The MPD pre-deployment module also checks with the authorization management server, in a step 211, that the selected servers are indeed authorized to be deployed. In the event that one or more of the selected servers do not meet this criterion, the MPD pre-deployment module may possibly proceed with a new selection of servers from among the available servers, until reaching the desired number of servers as declared in the declarative file FD. In a step 212, the MPD pre-deployment module obtains for example confirmation from the authorization management server that the selected servers are indeed all authorized to be used for partial configuration operations within the framework of a pre-deployment phase according to the present technique.

[0090] In a step 213, once the authorizations have been verified and confirmed, the pre-deployment module MPD uploads pre-deployment files into a GIT version control system associated with the deployment entity ED identified in the declarative file FD for the pre-deployment operation in question (for example, for the pre-deployment request referenced name_deployment_1 in the example of the, the pre-deployment files are uploaded into the version control system associated with the deployment entity referenced kanod_name_1). These pre-deployment files are for example constructed on the basis of the information declared in the declarative file FD and the technical characteristics of the servers finally selected, and they list all the useful information so that a deployment module MD of the deployment entity ED can carry out the required partial configuration of these servers.

[0091] By means of this transmission of the pre-deployment files, the pre-deployment entity EPD sends to the deployment entity ED a request to carry out the desired partial configurations of the selected servers, as defined in the declarative file FD. The deployment entity ED then carries out the required operations, according to a conventional mechanism close to that implemented in the context of a complete server configuration according to the prior art.

[0092] More particularly, in a step 214, the MD deployment module detects the presence of these new pre-deployment files in the GIT version management system associated with it. The MD deployment module then has the data useful for implementing the requested pre-deployments, namely the list of servers on which to operate these pre-deployments, and the way in which they must be configured, in particular in terms of operating system and deployment solution to be installed there, this solution comprising one or more components.

[0093] On this basis, the partial configuration operations are then implemented, in a step 215. In the example illustrated in, the deployment module MD proceeds for example respectively in steps 215, 215' and 215'' to the pre-deployment of several reserve servers, including in particular at least one SV-RC server located in regional data spaces ("Regional Clouds" in English), at least one SV-EC server located in end data spaces ("Edge Clouds" in English), and at least one SV-FEC server located in FEC border data spaces ("Far Edge Clouds" in English). According to a particular characteristic, once the partial configurations have been finalized, the deployment module MD of the deployment entity ED issues a shutdown or standby request to the servers concerned.In a step 216, the deployment module MD of the deployment entity ED also informs the pre-deployment module MPD that the requested pre-deployment operations have been carried out.

[0094] In a step 217, the MPD pre-deployment module confirms to the administrator (or the administration software system) that the partial configuration of the selected reserve servers has been correctly carried out, in accordance with the content of the FD declarative file.

[0095] At this point, the pre-deployment phase P1 according to the present technique is considered to be completed, and the system is ready for the implementation, if necessary, of a configuration finalization phase P2, in particular if an increase in the load of the communication service is detected.

[0096] This is a sequence diagram illustrating the implementation of such a configuration finalization phase P2, in a particular embodiment. This configuration finalization phase P2 is also implemented at the level of the pre-deployment entity EPD.

[0097] In a step 401, the pre-deployment module MPD of the pre-deployment entity EPD obtains a descriptive file of a deployment to be carried out, for example because a significant increase in load, and therefore the need to carry out scaling, has been detected. Such a file is for example uploaded by an administrator or generated and transmitted automatically to the pre-deployment module MPD by a third-party software system having detected the increase in load. According to a particular characteristic, the descriptive file comprises, possibly in addition to other information, at least one piece of information on a location of a server to be configured, in particular depending on the nature of the communication service requiring the increase in load.The deployment request may thus, for example, relate to a request for deployment in a particular data space among RC regional data spaces (“Regional Clouds” in English), edge data spaces (“Edge Clouds” in English), or FEC border data spaces (“Far Edge Clouds” in English). Thus, the descriptive file makes it possible, for example, to request, as a priority, a deployment in an FEC border data space when the communication service in question is associated with high requirements in terms of quality of service, in particular when the nominal operation of this service requires low latency.

[0098] Upon receipt of this file, the pre-deployment module MPD determines in a step 402 whether a server that has previously been partially configured as part of a pre-deployment phase P1 as already described in relation to the present features compatible with those required in the received descriptive file. Such a compatibility determination includes in particular a verification that the operating system and that the at least one component of an automated containerized application deployment solution installed on this partially configured server are indeed compatible with an implementation of the communication service in question.In the negative, if no server meets these criteria, the pre-deployment module MPD sends a classic deployment file, i.e. without pre-deployment P1, to the GIT version management system associated with the deployment entity ED, in order to trigger a classic deployment according to the prior art (i.e. a complete configuration of a new server by a classic deployment module). In the affirmative, when the pre-deployment module MPD identifies on the contrary at least one configuration server already partially configured in the pre-deployment phase P1 and with characteristics compatible with the deployment request descriptive file, for example the server SV_EC of the, this MPD module carries out in a particular embodiment various checks making it possible to ensure that this server can actually be used in the context of a scaling operation aimed at absorbing the increase in load that the service is undergoing.The MPD pre-deployment module issues, for example, in a step 403, a request to the BDD data structure associated with the group of reserve servers, in order to ensure that the SV_EC server in question is still available (that is to say, for example, that it has not already been requisitioned to contribute to the implementation of another service potentially also facing a peak load).

[0099] Upon receipt, in a step 404, of confirmation from the BDD data structure that the identified server is indeed available, the pre-deployment module MPD queries, in a step 405, the SGH authorization management server of the EPD pre-deployment entity, in order to verify that the identified compatible and available reserve server SV_EC is indeed authorized to be the subject of a configuration finalization operation according to the second phase P2. When the pre-deployment module MPD obtains, in a step 406, confirmation from the SGH authorization management server that this is indeed the case, it issues in a step 407 a new request to the BDD data structure, in order to reserve this SV_EC server, that is to say to remove it from the list of available reserve servers maintained in this database.Once this reservation information has been recorded in the BDD data structure, the MPD pre-deployment module receives confirmation in step 408 from the BDD data structure that the server identified as compatible has been removed from the list of available servers.

[0100] The MPD pre-deployment module then generates, on the basis of the deployment request descriptive file, at least one configuration information item making it possible to finalize the configuration of the selected compatible server, which it transmits to a MFD deployment finalization module of the EPD pre-deployment entity, in a step 409.

[0101] The MFD deployment finalization module then proceeds with the operations of finalizing the configuration of the selected SV_EC server, these operations including at least the configuration of at least one virtualization node according to the automated deployment solution of containerized applications preconfigured in this server, for the implementation of said service.

[0102] In a particular embodiment of the proposed technique, such configuration finalization operations comprise, for example, a sequence of different steps, according to which:

[0103] - the MFD deployment finalization module starts the SV_EC server whose configuration must be finalized, in a step 410;

[0104] - the MFD deployment finalization module installs an MK management node (for example a Kubernetes master node or “Kubernetesmasternode”) within this SV_EC server, in a step 411;

[0105] - the MFD deployment finalization module configures the installed MK management node, in a step 412, so that it instantiates one or more computing nodes (“Kubernetesworkernode”);

[0106] - the MFD deployment finalization module checks the state of the instantiated nodes, in a step 413;

[0107] - optionally, in steps 414 to 416, the MFD deployment finalization module requests (step 414) from the management node MK that it deploys (step 415) on the SV_EC server an application contributing to the deployed communication service, then the MFD deployment finalization module checks (step 416) the state of the application thus deployed.

[0108] At the end of the deployment finalization operations, and more particularly when it has been verified that they have been carried out successfully, the deployment finalization module MFD confirms to the pre-deployment module MPD, in a step 417, that the reserve server SV_EC is now completely configured and operational for the implementation of said service, and that it can in particular contribute to the absorption of the increase in the detected service load. The pre-deployment module MPD relays this information to the administrator (or to the administration software system) in a step 418. Device

[0109] According to another aspect, the proposed technique also relates to a pre-deployment entity, adapted to carry out the method of optimizing the sizing of a virtualization infrastructure to a load of a communication service, as previously described in any of its embodiments. Such an entity comprises means for partially configuring at least one server of a group of reserve servers, called pre-deployment means, implemented upstream of an increase in said load of the communication service. According to the present technique, these pre-deployment means comprise means for transmitting, to a deployment entity, a request for installation, on said at least one server, of an operating system and at least one component of an automated deployment solution for containerized applications deemed suitable for the implementation of said communication service.

[0110] La represents, in a schematic and simplified manner, the structure of a pre-deployment module of such a pre-deployment entity, in a particular embodiment. The pre-deployment module according to the proposed technique comprises for example a memory 51 consisting of a buffer memory M, a processing unit 52, equipped for example with a microprocessor μP, and controlled by the computer program Pg 53, implementing steps of the optimization method according to at least one embodiment of the invention. To this end, the device also comprises at least one communication interface (for example an Ethernet communication interface), allowing it to receive and transmit messages from and to other elements of the deployment entity, or third-party elements such as for example an administration software system, or a deployment entity.

[0111] Upon initialization, the code instructions of the computer program 53 are loaded into the buffer memory before being executed by the processor of the processing unit 52. The processing unit 52 detects at input E, for example, the presence of a declarative type file, the content of which describes information useful for implementing desired pre-deployment operations, including in particular information relating to an operating system and to components of an automated deployment solution for containerized applications to be deployed on one or more standby servers.

[0112] The microprocessor of the processing unit 52 then carries out the steps of the optimization method, according to the instructions of the computer program 53. More particularly, on the basis of the data contained in the declarative file received as input E, and of additional data possibly obtained from other elements of the pre-deployment entity – such as an authorization management server or a data structure associated with a group of reserve servers – the processing unit 52 selects at least one reserve server retained to be the subject of a partial configuration.The processing unit 52 then emits, at output S, a request for installation, on said at least one server, of the operating system and of the at least one component of the automated deployment solution for containerized applications deemed suitable for the implementation of the communication service according to the declarative file, so as to significantly reduce the duration of possible subsequent operations for finalizing the configuration of these servers, in particular in the event of detection of an increase in the load of the communication service.

Claims

Method for optimizing the sizing of a virtualization infrastructure to a load of a communication service, said method being implemented by a pre-deployment entity (EPD), said method being characterized in that it comprises, upstream of an increase (AC) of said load of the communication service, a partial configuration phase (P1) of at least one server of a group of reserve servers, called pre-deployment phase, comprising the transmission to a deployment entity (ED) of a request for installation, on said at least one server, of an operating system and at least one component of an automated deployment solution for containerized applications deemed suitable for the implementation of said communication service. Method according to claim 1, characterized in that said at least one component belongs to the group comprising:- a utility;- a computer library;- a configuration file;- an artificial intelligence engine;- an elementary component of said communication service. Method according to claim 1, characterized in that said pre-deployment phase is implemented on the basis of a declarative type file previously obtained by said pre-deployment entity. Method according to claim 3, characterized in that said declarative file comprises at least:- a type and a version of said operating system to be installed on said at least one server;- a type and a version of said automated containerized application deployment solution to be installed on said at least one server;- a number of servers to be partially configured within said group of reserve servers, for said types and versions of said operating system and of said automated containerized application deployment solution. Method according to claim 1, characterized in that said sending of an installation request is conditional on a prior verification, with an authorization management server: - that said deployment entity is authorized to carry out said installation within the framework of said pre-deployment phase; and / or - that said at least one server of said group of reserve servers is authorized to be the subject of said installation within the framework of said pre-deployment phase. Method according to claim 3, characterized in that said pre-deployment phase comprises: - obtaining, within a data structure associated with said group of reserve servers, at least one item of data identifying a set of servers available for the implementation of said communication service, within said group of reserve servers; - selecting, within said identified available servers, said at least one server which is the subject of said installation request, based on the content of said declarative type file and technical characteristics associated with said available servers, obtained in said data structure. Method according to claim 6, characterized in that said issuing of an installation request comprises the uploading, within a version management system associated with said deployment entity, of at least one deployment file comprising partial configuration information of said at least one selected server, said at least one deployment file being generated as a function of the content of said declarative file and said technical characteristics associated with said at least one selected server. Method according to claim 1, characterized in that it comprises, in response to an increase in load of said communication service: - the selection, from said at least one partially configured server in said pre-deployment phase, of at least one server whose partial configuration is compatible with a deployment request descriptive file obtained by said pre-deployment entity following detection of said increase in load; - the finalization of the configuration of said at least one selected partially configured server, delivering an operational server for the implementation of said communication service. Method according to claim 8, characterized in that a determination of the compatibility of said partial configuration with said deployment request descriptive file comprises a verification that the operating system and the at least one component of an automated containerized application deployment solution installed on said at least one selected partially configured server are compatible with the implementation of said communication service. Method according to claim 8, characterized in that said selection of said at least one server comprises taking into account a location of said at least one server, with regard to at least one location information included in said descriptive deployment request file, determined according to a nature of said communication service. Method according to claim 8, characterized in that said finalization of the configuration is conditional on a prior verification, with an authorization management server, that said at least one selected partially configured server is authorized to be the subject of said configuration finalization. Method according to claim 8, characterized in that said finalization of the configuration is conditioned on a prior verification, within a data structure associated with said group of reserve servers, that said at least one selected partially configured server is available for the implementation of said communication service. Method according to claim 8, characterized in that said finalization of the configuration comprises: - the generation, on the basis of said descriptive deployment request file, of at least one configuration information of said at least one selected partially configured server; - the configuration, on said at least one selected partially configured server, on the basis of said at least one configuration information, of at least one virtualization node according to said automated deployment solution of containerized applications, for the implementation of said communication service. Pre-deployment entity for optimizing the sizing of a virtualization infrastructure to a load of a communication service, said entity being characterized in that it comprises means for partial configuration of at least one server of a group of reserve servers, called pre-deployment means, implemented upstream of an increase in said load of the communication service, said pre-deployment means comprising means for transmitting, to a deployment entity, a request for installation, on said at least one server, of an operating system and at least one component of an automated deployment solution for containerized applications deemed suitable for the implementation of said communication service. 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 13, when executed by a computer.

Images