Process of deploying a service in a distributed environment.

Abstract

Method for deploying a service in a distributed environment. The invention relates to a method for deploying a service in a distributed environment, comprising deploying a plurality of software components of said service on a plurality of virtualization units.The method, implemented within a management node, comprises: - the instantiation (E1), within the virtualization units, of monitoring components configured to deliver metrics associated with the virtualization units and / or the deployed software components; - the recording (E2), within a configuration file, of interconnection data between some of said software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit; - the instantiation (E3), within the management node, of a control loop for the implementation, in an operating phase of said service, of iterations of control of compliance with predefined technical criteria, as a function of said metrics and said interconnection data. Abstract figure: Figure 1.

Description

Title of the invention: Method for deploying a service in a distributed environment. Technical field

[0001] The invention lies in the field of automated deployment of services on a set of computing resources. More particularly, the present invention relates to automated deployment techniques in a distributed environment, which make it possible to continuously guarantee compliance with predefined technical specifications during operation of the service, in order to ensure its nominal operation. Prior art

[0002] Many communication networks use virtualized functions instantiated on virtualization nodes hosted in virtual machines or in servers grouped into clusters, or "clusters" within data centers. In the remainder of the document, mention is made of virtualization nodes hosted in servers but it is understood that the teaching of this document also applies to the case of virtualization nodes hosted in virtual machines.

[0003] An example of managing the instantiation of virtualized functions is known as "Kubernetes". A Kubernetes architecture comprises at least one cluster of virtualization nodes. Such a cluster of virtualization nodes comprises at least a first node called a management node, or "Kubernetes master node", and a plurality of computing nodes, or "Kubernetes worker node" intended to instantiate virtualized functions.

[0004] The management node includes, among other things, a database called ETCD which consists of a dynamic configuration register of the computing nodes.

[0005] A computing node comprises a plurality of virtualization units or "pods". Each virtualization unit is provided with resources enabling the execution of one or more 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 files. reference.

[0008] The ETCD database also being accessible by a virtualization node deployment entity, the latter regularly reads the content 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 the needs.

[0009] The deployment of a virtualization node on a computer server consists, for example, of downloading onto a computer server a file containing an operating system as well as a set of applications necessary for the deployment of the virtualization node, then starting the computer server using the downloaded file.

[0010] It is also possible to deploy multiple virtualization nodes on a single computer server through the use of virtual machines. In this case, once the file is downloaded to the computer server, a virtual machine is started using the downloaded file.

[0011] In an effort to reduce operating costs and improve the flexibility of network infrastructures, cloud computing architectures are most often distributed or multi-site architectures in which the servers hosting the virtualization nodes belonging to the same cluster of nodes can be located on separate and distant geographical sites. Thus, certain virtualized functions requiring, for example, low latency, tend to be executed by virtualization units deployed in servers located at the edge of communications networks, i.e. as close as possible to the user terminals requiring a given service, while virtualized functions that are less demanding in terms of latency but process large volumes of data are instead instantiated in centralized data centers, generally of a larger size.

[0012] While they generally integrate load distribution mechanisms (such as, for example, a mechanism known as “Horizontal Pod Autoscaling”, 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 deployed service), the Kubemetes architecture and other existing automated service deployment solutions do not, however, currently offer means of continuously guaranteeing the satisfaction of predefined technical constraints (e.g., imposed in advance by a user operating the service), in terms, for example, of minimum resources to be allocated or network performance to be respected during the service operation phase, in particular when this service is to be deployed in a distributed environment, with software components distributed over infrastructures. structures potentially located on distinct and distant geographical sites.

[0013] For certain critical applications, compliance with such technical constraints may nevertheless prove essential, a failure or even a simple slowdown of the service sometimes being likely to have significant undesirable consequences, in particular when user security depends on the proper functioning of the service. Even for less critical applications, there is a risk that users will turn away from a service in the event of repeated degradation of the user experience, if the minimum resources to ensure nominal operation of the service are not continuously guaranteed.

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

[0015] 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 automated deployment of a service in a distributed environment, comprising the deployment of a plurality of software components of said service on a plurality of virtualization units within said distributed environment. According to the general principle of the proposed invention, such a method, implemented within a management node of the distributed environment, comprises:

[0016] - the instantiation, within at least one of said virtualization units, of at least a monitoring component configured to deliver at least one metric associated with said virtualization unit and / or at least one of said software components deployed on said virtualization unit;

[0017] - recording, within a configuration file, at least one piece of data interconnection between software components of said plurality of software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;

[0018] - the instantiation, within said management node, of a control loop for the implementation, in an operating phase of said service, of at least one iteration of monitoring compliance with at least one predefined technical criterion, based on said metrics delivered by at least one of said monitoring components and said interconnection data recorded within said configuration file.

[0019] In this way, the conditions are met to allow the implementation of a control loop in a distributed environment, thanks to an advanced solution for the automated deployment of containerized applications which includes complementary mechanisms making it possible on the one hand to obtain, via monitoring components, metrics at the level of the different containers deployed in the distributed environment, but also on the other hand to make the link between these different containers and therefore these different metrics, by means of interconnection data recorded at the level of a common configuration file. In this way, the control loop has all the information allowing it to control compliance with predefined technical specifications during the operation phase of the service, even when this service is deployed in a distributed environment.

[0020] In a particular embodiment, said instantiation of at least one monitoring component within at least one of said virtualization units is implemented jointly or concomitantly with the deployment of at least one of said software components on said virtualization unit.

[0021] In this way, the control loop is functional as soon as the service is deployed, and the continuous monitoring of compliance with the predefined technical criteria is operational from the outset, that is to say as soon as the service becomes available to its users.

[0022] In a particular embodiment, said software components, said interconnections between software components, and said technical criteria are defined within a declarative type file, said deployment being carried out according to the content of said declarative type file.

[0023] In this way, the deployment of the service and an associated control loop is particularly simple to implement for an operator of said service, since it is sufficient for him to declare within a simple file, via key-value type entries, the containers to be deployed, the links which exist between some of these containers, and the objectives to be guaranteed for chosen technical criteria (expressed for example in the form of minimum and / or maximum values ​​to be respected) in relation to the declared containers and links.

[0024] In a particular embodiment, said recording of interconnection data within the configuration file and said instantiation of the control loop are initiated upon request from a dedicated application, based on data collected by said dedicated application following the deployment of said software components and the instantiation of said monitoring components on said virtualization units.

[0025] In this way, the operations of obtaining, selecting and formatting data relevant to the operation of the control loop are facilitated, thanks to the use of an application specifically developed for this purpose.

[0026] In a particular embodiment, at least one iteration implemented by said control loop comprises a check of compliance with at least one technical criterion representative of at least one resource allocated for the implementation of at least at least one of said software components.

[0027] According to a particular characteristic of this embodiment, said at least one technical criterion representative of at least one allocated resource belongs to the group comprising:

[0028] - a minimum amount of disk space;

[0029] - a minimum amount of RAM;

[0030] - a minimum amount of processor availability.

[0031] In a particular embodiment, at least one iteration implemented by said control loop comprises a check of compliance with at least one technical criterion representative of at least one target performance for the implementation of at least one interconnection link between said software components.

[0032] According to a particular characteristic of this embodiment, said at least one technical criterion representative of at least one target performance belongs to the group comprising:

[0033] - a maximum latency on said interconnection link between said components software;

[0034] - a maximum jitter on said interconnection link between said software components

[0035] - a maximum data loss rate on said interconnection link between said software component.

[0036] In this way, it is possible to ensure that minimum resources and performance are guaranteed for optimal operation of the service, both at an intra-container level (i.e. within each container) and at an inter-container level (i.e. in the interactions between containers).

[0037] In a particular embodiment, said method comprises, prior to or at the start of each control iteration of said control loop, a step of verification, within said configuration file, by said monitoring components, of a current validity of said interconnection data between software components.

[0038] In this way, any change in the configuration of the deployed service is detected quickly, which allows for on-the-fly re-parameterization of the control loop and monitoring components if necessary. Optimal continuous operation of the control loop is thus ensured.

[0039] In a particular embodiment, said method comprises, when at least one of said predefined technical criteria is not respected, the execution of a corrective action in connection with at least one of said software components and / or at least one of said virtualization units.

[0040] In this way, any detection of non-compliance with one of the predefined technical criteria results in an immediate reaction from the system, aimed at restoring the system as quickly as possible. compliance with said criterion. Thus, the conditions for nominal operation of the service are continuously guaranteed.

[0041] In a particular embodiment, at least one of said predefined criteria is associated with the operation of said service.

[0042] In a particular embodiment, said service is a cloud radio access network (CRAN), and said software components comprise at least one radio unit (RU), at least one distributed unit (DU), and at least one centralized unit (CU).

[0043] In this way, the implementation of mechanisms allowing compliance with the high performance requirements associated with the operation of a cloud radio access network is greatly facilitated, and the risks of failure or desynchronization of the different elements of such a service are significantly reduced.

[0044] According to another aspect, the invention relates to a device for deploying a service in a distributed environment, comprising means for deploying a plurality of software components of said service on a plurality of virtualization units within said distributed environment. Such a device implements a management node of said distributed environment and comprises:

[0045] - instantiation means, within at least one of said virtualization units, of at least one monitoring component configured to deliver at least one metric associated with said virtualization unit and / or at least one of said software components deployed on said virtualization unit;

[0046] - means for recording, within a configuration file, at least one interconnection data between software components of said plurality of software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;

[0047] - means for instantiating, within said management node, a loop of control for the implementation, in an operating phase of said service, of at least one iteration of control of compliance with at least one predefined technical criterion, based on said metrics delivered by at least one of said monitoring components and said interconnection data recorded within said configuration file.

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

[0049] 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 such as described above in any of its embodiments, when this method is executed on a computer.

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

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

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

[0053] The different embodiments mentioned above can be combined with each other for implementing the invention. Figures

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

[0055] [Fig-1] schematically presents the main stages of a de- deployment of a service, in a particular embodiment of the proposed technique;

[0056] [Fig.2] presents a sequence diagram illustrating the deployment of a cloud access network service within a Kubemetes architecture, in a particular embodiment of the proposed technique;

[0057] [Fig.3] presents an example of the content of a declarative file of technical criteria to be guaranteed during the operational phase of a service, in a particular embodiment of the proposed technique;

[0058] [Fig.4] describes a simplified architecture of a management node for implementing the proposed technique, in a particular embodiment of the proposed technique. Detailed description of the invention General principle

[0059] The technique described below makes it possible to overcome some of the drawbacks aforementioned.

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

[0061] According to a first aspect, the present technique relates to a method for automated deployment of a service in a distributed environment. The term "service" is understood here in the broad sense, and includes for example, by way of illustration and not limitation, the implementation of one or more virtualized applications and / or functions allowing the provision of a set of functionalities. By "distributed environment", is also meant in the context of the present document an environment in which the different resources which serve as support for the implementation of the service in question are distributed in a plurality of servers, clusters of servers and / or data centers not necessarily located in the same geographical location (in the context of a Kubemetes architecture, such an environment can be described as "multi-cluster").Typically, the deployment of the service in such an environment includes the deployment of a plurality of software components of this service on a plurality of virtualization units within the distributed environment. This distribution of the software components, and therefore of the processing, however makes performance control operations more complex, as traditional solutions for automated deployment of containerized applications, such as Kubernetes for example, do not natively integrate mechanisms to guarantee at all times the availability of the resources (CPU, RAM, etc.) allocated to each virtualization unit or minimum performance (for example network performance, energy performance, etc.) to be respected for data exchanges between the different software components of the service.The proposed technique relates more particularly to improvements to these existing solutions for automated deployment of containerized applications, making it possible to overcome these drawbacks.

[0062] Thus, the general principle of the proposed technique, illustrated in relation to [Fig.l], is based on an improved deployment process, enriched with new steps introduced below, comprising, at the level of a distributed environment management node:

[0063] - the instantiation El, in the virtualization units within which the different software components of the service to be deployed are implemented, monitoring components configured to deliver at least one metric associated with the virtualization unit and / or software component considered;

[0064] - the E2 recording, within a configuration file, of at least one piece of data interconnection between interconnected software components for the implementation of the service to be deployed, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;

[0065] - the instantiation E3, within the management node, of a control loop for the implementation, in a service operating phase, of at least one iteration of monitoring compliance with predefined technical criteria associated with the operation of the service, based on the metrics delivered by the monitoring components and the interconnection data recorded within the configuration file.

[0066] In other words, mechanisms are provided not only to set up a control loop to ensure compliance with technical specifications imposed for example by a user operating the service, but also to ensure that this control loop has all the data necessary to carry out this control, namely:

[0067] - data (eg measurements) associated with the operation of each component software or virtualization unit within which it is deployed, through the instantiation in each of these virtualization units of dedicated monitoring components to deliver such metrics; and

[0068] - data which can be qualified as synchronization data, in that that they make it possible to link software components which, although interconnected for the implementation of the service, do not necessarily have knowledge of their respective existence, of the existence of monitoring components other than their own, and / or of the resources on which they are deployed, thanks to a pooling of at least part of this information within a shared configuration file available at the level of a management node.

[0069] According to the general principle previously described, the control loop thus has access to correlated information received from the various software components and monitoring components which are dependent on each other and interconnected, which allows it to operate in a distributed environment.

[0070] According to a particular characteristic, the mechanisms previously described can be implemented as soon as the service is deployed in the distributed environment, in other words jointly or concomitantly with the deployment of the software components of this service in the distributed environment.

[0071] Alternatively, according to another particular characteristic, their implementation can also be disjointed from the software component deployment phase. Steps E1, E2 and E3 introduced previously are then implemented in a later phase, in relation to a service already deployed or potentially already operated, possibly at the request of a third-party entity authorized - for example by delegation of a certification authority - to request the deployment of such control mechanisms from the management node. Presentation of a particular embodiment

[0072] In the remainder of the document, the invention is described in more detail using the example of the automated deployment of a cloud radio access network, or Cloud-RAN (Cloud Radio Access Network in English), of a communications network. The proposed solution is in fact particularly interesting in the context of the deployment of such a service, for several reasons.

[0073] First, the deployment of a cloud radio access network is generally implemented at the edge of a communication network, which implies moving away from conventional architectures often implemented on a single geographical site, in favor of architectures distributed over a larger territory, which corresponds to a type of architecture targeted by the proposed technique. The software components of the cloud radio access network - which comprise at least one radio unit RU, at least one distributed unit DU, and at least one centralized unit CU - are thus generally required to be deployed on distributed sites. In addition, a unique association between a CU and a DU as well as between a DU, an RU and an antenna must be instantiated.The introduction and consideration of interconnection data, as proposed with the present technique, allows simplified management of this type of distributed architecture, by allowing, via the sharing of a common configuration file, the exchange of configuration data between the different containers allowing the deployment of the cloud access network, and more particularly the sharing of the addressing information of the containers comprising the CU, DU and RU entities. In this way, the DU is able to know the IP address of the RU, the DU is able to know the IP address of the CU, etc.

[0074] Secondly, for optimal operation of such a cloud radio access network, subject to high performance requirements, compliance with strict technical constraints is required. For example, in terms of network performance, it is necessary for the distributed unit DU to permanently maintain a connection with a latency of less than one millisecond (for a one-way trip) with a radio unit RU, a higher latency being likely to cause desynchronization of the different elements of the cloud radio access network, and therefore to compromise the proper operation of this service. Similarly, it is necessary to guarantee compliance with a minimum resource allocation for the implementation of the different constituent elements of the cloud radio access network, in order to avoid any failure of the service.

[0075] [Fig.2] illustrates a sequence diagram corresponding to a particular embodiment of the present technique, in which the DEP deployment of such a cloud radio access network is implemented via a Kubernetes orchestration solution (it being understood that the general principle presented and the steps described below remain substantially the same for the deployment of services other than a Cloud-RAN and / or via automated containerized application deployment solutions other than Kubernetes).

[0076] In the particular embodiment illustrated, the deployment DEP of the cloud access network is initiated following the uploading or detection, within a management node NG of the distributed environment, in a step 1, of a declarative type file FD, the content of which describes the software components to be deployed, the interconnections between some of these software components, and technical criteria (or specifications) to be guaranteed when these software components are in operation, i.e. in a subsequent phase of operation EXP of the service. An example of an extract of the content of such a file for the deployment of a Cloud-RAN is illustrated in relation to [Fig.3]. More particularly, such a file FD lists software components 31 to be deployed (in this case, for the deployment of a cloud access network, CUs, DUs and RUs) as well as technical characteristics to be guaranteed in relation to these software components.

[0077] According to a particular characteristic, these technical criteria can be divided into two main categories: a first category 32 comprising criteria representative of allocated resources to be guaranteed for the implementation of the software component considered (or of the virtualization unit on which it is instantiated), and a second category 33 comprising criteria representative of target performances to be guaranteed for the implementation of at least one interconnection link between the software component considered and at least one other software component or another entity (for example an antenna) involved in the implementation of the service to be deployed.

[0078] By way of non-limiting examples, the first category 32 includes at least one of the following criteria:

[0079] - a minimum amount of processor availability 321 to be guaranteed;

[0080] - a minimum amount of RAM 322 to be guaranteed;

[0081] - a minimum amount of disk space 323 to be guaranteed.

[0082] By way of non-limiting examples, the second category 33 includes for example at least one of the following criteria:

[0083] - a maximum latency 341 to be guaranteed on the interconnection link considered;

[0084] - a maximum jitter 342 to be guaranteed on the interconnection link considered;

[0085] - a maximum data loss rate 343 to be guaranteed on the interconnection link considered.

[0086] In addition to the preceding examples 341, 342 and 343 relating more particularly to criteria representative of target network performances, the second category 33 can also comprise performance criteria of other types, not shown in [Fig. 3], such as for example:

[0087] - a maximum energy consumption to be guaranteed (for example a maximum power consumption in watts per hour) for data exchanges on the interconnection link in question;

[0088] - energy efficiency to be guaranteed for data exchanges on the link interconnection considered;

[0089] - a maximum occupancy rate to be guaranteed for at least one buffer zone of packets or requests used for data exchanges on the interconnection link considered;

[0090] - a minimum and / or maximum packet or request buffer size to guarantee for data exchanges on the interconnection link in question;

[0091] - a minimum and / or maximum value to be guaranteed for at least one associated parameter to support a transport sub-function (for example a number of HARQ contexts on a satellite link, or multiple “multipath”, etc.) on the interconnection link considered.

[0092] The declarative file also describes the interconnection links 34 to which the technical criteria of the second category 33 are attached. Thus, in the example of the extract from the FD file for the deployment of a cloud access network type service, interconnection links 34 between CU and DU, between DU and RU, and between RU and antenna are declared. As illustrated in [Fig. 3], several interconnections with the same software component can be declared within such an FD file: thus, in the FD file extract provided as an example, the CU is declared as being interconnected with a DU, but also with another entity identified by an identifier “Other-Target-ID”, different technical network performance criteria being able to be associated with each of these interconnection links.

[0093] In the context of a deployment orchestrated by Kubernetes, the declarative FD file takes, for example, the form of a custom resource definition file (“Custom Resources”), the content of which is injected into the ETCD database by the NG management node, in step 2 of [Fig.2].

[0094] Upon detection, in a step 3, of these personalized resources in the ETCD base, various mechanisms are triggered by a Kubernetes OP1 operator implemented within the NG management node within the framework of the present technique.

[0095] More particularly, the operator OP1, called the deployment operator, creates a configuration file FC, in a step 4. This configuration file, substantially empty at this stage of the method, is intended to serve as a location for recording configuration information during the deployment phase DEP, which will subsequently be used in the operating phase EXP of the service to correlate the various data received and carry out the various operations for controlling the technical criteria to be guaranteed. In the context of a Kubernetes deployment, such a file may for example take the form of an object of the “ConfigMap” type.

[0096] In steps 5, 5' and 5”, the deployment operator OP1 then proceeds not only to deploy the various CL software components of the service on virtualization units UV of the distributed environment, but also, concomitantly or jointly with this deployment, to instantiate, within these virtualization units, the associated CS monitoring components. Typically, for the deployment of a cloud access network (Cloud-RAN) type service, CL software components of type CU, DU and RU and associated CS monitoring components are deployed on virtualization units UV_CU, UV_DU and UV_RU within computing nodes NC located in three distinct geographical areas, i.e.respectively in regional data spaces RC ("Regional Clouds" in English), end data spaces EC ("Edge Clouds" in English), and border data spaces FEC ("Far Edge Clouds" in English), such spaces being notably defined by the O-RAN ("Open Radio Access Network" in English) alliance. When they are instantiated, the different CS monitoring components are notably configured so as to be able to access in read / write mode the FC configuration file previously created in step 4.

[0097] In steps 6, 6' and 6”, installation and / or deployment information generated by Kubernetes following the deployment of the CL software components and the CS monitoring components on the different virtualization units UV_CU, UV_DU and UV_RU is collected by a dedicated application APP. Such information, transmitted by the CS monitoring components to the APP application, includes for example data associated with the NC computing nodes, the UV_CU, UV_DU and UV_RU virtualization units, the software components and / or the monitoring components themselves. This data includes for example identifiers generated for these different entities, IP addresses (possibly associated with ports) which are assigned to them and at which they can be contacted, etc.

[0098] The dedicated application APP is then responsible for filtering and formatting the relevant data for the implementation of a control loop among this collected information, then requesting from the management node NG the recording in the previously created FC configuration file of this relevant data in a step 7. The filtering consists for example of sorting the collected information to keep only that related to the technical criteria to be controlled, and the formatting to transcribe this relevant data in a format compatible with the FC configuration file and subsequently interpretable by the different entities requested for the control (control loop operator, monitoring components, etc.). In this way, information generated following the deployment of the CU, DU and RU software components are associated and centralized in a single location, which allows for synchronization between this information, useful for the implementation of a BC control loop created subsequently, in particular to carry out inter-entity control (the different components deployed not being aware of each other's existence, for example the CS monitoring component of the CU is not aware of the existence of the CS monitoring component of the DU, the CS monitoring component of the DU is not aware of the existence of the CS monitoring component of the RU etc.).Also, step 7 makes it possible, for example, to associate at least one identifier of a virtualization unit, of a software component and / or of a monitoring component with at least one identifier respectively of another virtualization unit, of another software component and / or of another monitoring component, at least a portion of said identifiers being allocated following the deployment of the service.

[0099] In a step 8, the dedicated application APP also requests the creation of the control loop BC from the management node NG. The control loop BC is for example implemented by means of a Kubernetes object of type “ClosedLoop” whose parameters are recorded in a step 9 in the ETCD database. These parameters typically include dependency parameters between the virtualization units (i.e. the interconnection links) and a list of technical criteria to be controlled (i.e. the allocated resources and / or target performances to be guaranteed). In a step 10, a Kubernetes OP2 control loop operator implemented within the management node NG detects these parameters (which can take the form of personalized Kubernetes resources) in the ETCD database, which finalizes the operations of instantiating the control loop BC, which is then operational.

[0100] At this stage, the initial deployment phase DEP according to the present technique can be considered as completed, and an exploitation phase EXP of the service can begin, corresponding to a use of the service in question under continuous control of the control loop BC.

[0101] In this operating phase EXP, the control loop BC repeatedly implements iterations of checking compliance with the predefined criteria declared in the declarative file FD, based on the metrics delivered by the monitoring components and the interconnection data recorded within the configuration file FC.

[0102] Each control iteration more particularly comprises steps 11 to 16 of [Fig.2], detailed below.

[0103] Firstly, in steps 11, 11' and 11”, the various CS monitoring components carry out a verification, within the FC configuration file, of a current validity of the interconnection data between software components. A such verification aims to ensure that the configuration is still the expected one, in particular that the affiliations made between CU, DU, RU, and other elements, for example antenna type A, remain valid. Indeed, an event related to a deployed component - for example a software or hardware problem - could have led to the need to redeploy this component, and therefore to lead to a modification of its configuration, in which case it is necessary to reconfigure the control loop BC before being able to use it. In other words, in these steps 11, 11' and 11”, the CS monitoring components use the FC configuration file to configure or possibly reconfigure their monitoring processes.

[0104] In order to adapt to these possible parameter changes, in a step 12, the control loop operator OP2 continuously monitors the modifications made to the “ClosedLoop” type object in the ETCD database.

[0105] Once these checks and possible adaptations have been carried out, the effective control of the predefined technical criteria is implemented.

[0106] Firstly, in steps 13, 13' and 13”, the CS monitoring components measure and / or collect various data, in order to deliver various metrics associated with the virtualization units or the software components. As illustrated in [Fig.3], these metrics can be of the intra-entity or inter-entity type, the intra-entity metrics being for example related to currently allocated resources (RAM, CPU, disk space, etc.) within an entity (typically a virtualization unit UV_CU or UV_DU or UV_RU), and the inter-entity metrics being for example related to current performances on an interconnection link between entities (typically between two virtualization units, between UV_CU and UV_DU, or between UV_DU and UV_RU or even between UV_RU and Antenna A).

[0107] In steps 14, 14' and 14”, the CS monitoring components upload these different metrics by updating their data in the “ClosedLoop” object of the ETCD database.

[0108] Based on these metrics, the control loop operator OP2 can evaluate whether all the technical criteria predefined in the declarative file FD are respected. If not (i.e. if at least one of these criteria is not respected), the control loop operator OP2 triggers, in steps 15, 15' and 15”, at least one corrective action in connection with at least one of said software components and / or at least one of said virtualization units, so that compliance with all the technical criteria is again verified.

[0109] Such corrective actions include, by way of purely illustrative and non-limiting examples, an increase in the RAM or processor capacity available on a virtualization unit, an increase in the number of computing nodes and / or virtualization units, a redistribution of software components on the various infrastructures available to reduce potential problems linked to concurrent access to the processor or RAM, particularly when several services are deployed and operated concurrently, etc.

[0110] In a particular embodiment, in an optional step 16, the control loop operator OP2 transmits to the dedicated application APP trace data of the control operations carried out (e.g. the values ​​of certain key metrics, the corrective actions taken, etc.), for the implementation of possible subsequent additional processing. The dedicated application APP can thus, for example, expose this data via one or more application programming interfaces (APIs), so that it can be used by third-party tools.

[0111] Although it is described previously in embodiments related to the deployment of a cloud access network, the present technique is however not limited to such use, which is given solely for illustrative purposes. The proposed technique is in fact of particular interest for the deployment in a distributed environment of any containerized application that must meet high performance requirements. Thus, many use cases are conceivable, in particular in industrial systems involving numerous interconnected devices, in which the reaction time of the system is a critical factor for ensuring the safety of people, and for which rapid processing times and very low latencies are therefore required at all times.This could involve, for example, urgently shutting down the operation of one or more machine tools if a potentially remote decision-making body detects, on the basis of data sent by a network of cameras and other sensors, that the physical integrity of a user is threatened.

[0112] The proposed technique, in its general principle and its different embodiments, can also be implemented in connection with other solutions for automated deployment of containerized applications than Kubemetes.

[0113] Furthermore, alternatives for implementing some of the steps described in relation to [Fig.2] may be envisaged, in other embodiments of the present technique.

[0114] For example, direct input via a human-machine interface made available to an operator user can be envisaged instead of using the FD declarative file introduced in relation to step 1, to communicate to the management node the information relating to the software components to be deployed, to the possible interconnections between some of these software components, and to the technical criteria to be guaranteed.

[0115] Similarly, alternatives to using a dedicated application (the APP application of [Fig.2]) may be considered in relation to steps 6, 6', 6”, 7 and 8 previously described, the operations implemented within the framework of these steps can, according to a particular characteristic, be managed directly by the NG management node, for example by means of a new Kubernetes synchronization operator.

[0116] In certain embodiments, steps 11, 11' and 11” of verifying, within the configuration file FC, a current validity of the interconnection data between software components may possibly be optional, or at the very least not be implemented at each iteration of the control loop BC but at a lower frequency (for example every two, ten, or one hundred iterations). Device

[0117] According to another aspect, the proposed technique also relates to a device for deploying a service in a distributed environment, capable of carrying out the method previously described in any of its embodiments. Such a device comprises means for deploying a plurality of software components of said service on a plurality of virtualization units within said distributed environment, these deployment means being implemented via a management node of said distributed environment implemented in said device. This device further comprises the following means, implemented by said management node:

[0118] - means of instantiating, within one of said virtualization units, a monitoring component configured to deliver at least one metric associated with said virtualization unit and / or said software component deployed on said virtualization unit;

[0119] - means for recording, within a configuration file, at least one interconnection data between software components of said plurality of software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;

[0120] - means for instantiating, within said management node, a loop of control for the implementation, in an operating phase of said service, of at least one iteration of control of compliance with at least one predefined technical criterion, based on said metrics delivered by at least one of said monitoring components and said interconnection data recorded within said configuration file.

[0121] [Fig.4] represents, in a schematic and simplified manner, the structure of such a device, in a particular embodiment. The device according to the proposed technique comprises for example a memory 41 consisting of a buffer memory M, a processing unit 42, equipped for example with a microprocessor qP, and controlled by the computer program Pg 43, implementing steps of the method for automated deployment of a service in a distributed environment 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 equipment present in the distributed environment and contributing to the implementation of a service to be deployed.

[0122] At initialization, the code instructions of the computer program 43 are loaded into the buffer memory before being executed by the processor of the processing unit 42. The processing unit 42 detects at input E for example the presence of a declarative type file, the content of which describes software components to be deployed for the implementation of a service in a distributed environment, possible interconnections between some of these software components, and technical criteria to be guaranteed when these software components are in operation, that is to say in a subsequent phase of operation of the service.

[0123] The microprocessor of the processing unit 42 then carries out the steps of the method for automated deployment of the service in the distributed environment, according to the instructions of the computer program 43. More particularly, on the basis of the data contained in the declarative file received as input E, the processing unit 42 carries out operations complementary to the raw deployment of said service, comprising the instantiation of monitoring components associated with the software components of the service, the recording of interconnection data between said software components in a configuration file.The processing unit 42 finally instantiates, at output S, a control loop for the implementation, in a subsequent phase of operation of said service, of at least one iteration of control of compliance with predefined technical criteria associated with the operation of said service, carried out on the basis of metrics delivered by said monitoring components and as a function of the interconnection data recorded in said configuration file.

Claims

Claims

1. Method for deploying a service in a distributed environment, comprising deploying a plurality of software components of said service on a plurality of virtualization units within said distributed environment, said method being implemented within a management node of said distributed environment and characterized in that it comprises: - instantiating (El), within at least one of said virtualization units, at least one monitoring component configured to deliver at least one metric associated with said virtualization unit or at least one of said software components deployed on said virtualization unit; - recording (E2), within a configuration file, at least one interconnection data item between software components of said plurality of software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit;- the instantiation (E3), within said management node, of a control loop for the implementation, in an operating phase of said service, of at least one iteration of control of compliance with at least one predefined technical criterion, as a function of said at least one metric delivered by at least one of said monitoring components and of said at least one interconnection data recorded within said configuration file.;

2. Method according to claim 1 characterized in that said instantiation of at least one monitoring component within at least one of said virtualization units is implemented jointly or concomitantly with the deployment of at least one of said software components on said virtualization unit.

3. Method according to claim 1 characterized in that said software components, said interconnections between software components, and said technical criteria are defined within a declarative type file, said deployment being carried out according to the content of said declarative type file.

4. Method according to claim 1, characterized in that said recording of interconnection data within the configuration file and said instantiation of the control loop are initiated on request from a dedicated application, based on data collected by said dedicated application following the deployment of said software components and the instantiation of said monitoring components on said virtualization units.

5. Method according to claim 1, characterized in that at least one iteration implemented by said control loop comprises a check of compliance with at least one technical criterion representative of at least one resource allocated for the implementation of at least one of said software components.

6. Method according to claim 1, characterized in that at least one iteration implemented by said control loop comprises a check of compliance with at least one technical criterion representative of at least one target performance for the implementation of at least one interconnection link between said software components.

7. Method according to claim 5, characterized in that said at least one technical criterion representative of at least one allocated resource belongs to the group comprising: - a minimum amount of disk space; - a minimum amount of RAM; - a minimum amount of processor availability.

8. Method according to claim 6, characterized in that said at least one technical criterion representative of at least one target performance belongs to the group comprising: - a maximum latency on said interconnection link between said software components; - a maximum jitter on said interconnection link between said software components; - a maximum data loss rate on said interconnection link between said software components.

9. Method according to claim 1, characterized in that it comprises, prior to or at the start of each control iteration of said control loop, a step of verification, within said configuration file, by said monitoring components, of a current validity of said interconnection data between software components.

10. Method according to claim 1 characterized in that it comprises, when at least one of said predefined technical criteria is not respected, the execution of a corrective action in connection with at least one of said software components and / or at least one of said vir- realization.

11. Method according to claim 1 characterized in that at least one of said predefined criteria is associated with the operation of said service.

12. A method characterized in that said service is a cloud radio access network (CRAN), and in that said software components comprise at least one radio unit (RU), at least one distributed unit (DU), and at least one centralized unit (CU).

13. Device for deploying a service in a distributed environment, comprising means for deploying a plurality of software components of said service on a plurality of virtualization units within said distributed environment, said device implementing a management node of said distributed environment and being characterized in that it comprises: - means for instantiating, within at least one of said virtualization units, at least one monitoring component configured to deliver at least one metric associated with said virtualization unit and / or at least one of said software components deployed on said virtualization unit;- means for recording, within a configuration file, at least one interconnection data item between software components of said plurality of software components, associating at least one identifier of a virtualization unit and at least one identifier of another virtualization unit; - means for instantiating, within said management node, a control loop for implementing, in an operating phase of said service, at least one iteration of checking compliance with at least one predefined technical criterion, as a function of said at least one metric delivered by at least one of said monitoring components and said at least one interconnection data item recorded within said configuration file.;

14. 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 12, when executed by a computer.

Images