Module, method, and program using a data affinity constraint for service deployment

Abstract

A module is proposed for use in a cloud computing environment. The module is designed to operate on a data processing system comprising a set of resources (210, 212, 220, 230, 310, 320, 330). This set of resources includes a source resource (212, 220) used for the initial deployment of a service. The module is configured to: evaluate (110), within the set of resources, at least one potential resource (210, 212, 220, 230, 310, 320, 330) for a new service deployment using an affinity function that takes into account at least one constraint related to a data topology associated with the service and / or a data processing system architecture; and, when an evaluation result for a potential resource is favorable, identify (112) the potential resource as the destination resource for implementing an operation. cloning resulting in the new deployment of the service...Figure from the summary: Figure 1.

Description

Title of the invention: Module, method and program using a data affinity constraint for service deployment Technical field

[0001] The present disclosure is in the field of information and communications technologies, and more specifically in the field of telecommunications system architectures based on virtualized functions hosted in a cloud computing environment.

[0002] It relates to a module, a non-uniform memory access system comprising such a module, a method implemented by such a module, and a computer program for implementing such a method. Prior art

[0003] The state of the art includes systems that use containerization technologies, such as Docker, and container orchestration technologies, such as Kubemetes.

[0004] These systems are designed to deploy applications and services on data processing agglomerations, or "clusters", by distributing them across several working environments, or "clouds".

[0005] However, these existing systems do not provide means to replicate configurations of services or applications deployed on one cloud in another.

[0006] Furthermore, they also do not provide a suitable routing reconfiguration mechanism to optimize the use of these services or applications following such replication. Summary

[0007] The invention aims to improve the situation.

[0008] According to one aspect, there is provided a module in a cloud computing environment, the module being adapted to operate on a data processing system comprising a set of resources, the set of resources including a source resource involved in an initial deployment of a service, the module being configured to: evaluating, within the set of resources, a potential resource for a new deployment of the service using an affinity function taking into account at least one constraint relating to a topology of data associated with the service and / or to an architecture of the data processing system, and when an evaluation result of a potential resource is favorable, identify the potential resource as a destination resource for implementing a cloning operation resulting in the new deployment of the service.

[0009] Such a module allows for a new, optimized and efficient deployment of the service due to the prior evaluation, using the affinity function, of one or more potential resources.

[0010] In one example, the module is further configured to update the data topology in connection with the new deployment of the service.

[0011] This update allows the data topology to evolve dynamically and ensures that the data remains consistent and optimized.

[0012] In one example, the module is further configured to transmit an update message regarding the updated data topology and / or a configuration of the new deployment to at least one third-party module.

[0013] Transmitting update messages enables proactive communication with other modules or systems and facilitates seamless integration and collaboration between the affected modules or systems.

[0014] In one example, the module is further configured to collaborate with an orchestrator to update a routing in accordance with the updated data topology and the new service deployment.

[0015] Updating the routing ensures optimized routing for the new deployment.

[0016] In one example, the data topology provides information on a neighborhood of each data commonly associated with the service.

[0017] This allows for a better understanding of the relationships and dependencies involving, at least, the data associated with the service and possibly other data and / or other services. This increased understanding can be used to define a variety of rules that can be used to evaluate potential resources.

[0018] In one example, said at least one constraint comprises at least one of a latency constraint, a bandwidth constraint, a load constraint, a cost constraint, an isolation constraint, a security constraint, an access potential constraint, a geographical location constraint of the potential resource and a non-overlap constraint of the destination resource and a memory resource of the data processing system.

[0019] These different constraints can be considered together or separately and offer the possibility of a detailed, complete and precise evaluation of one or more potential resources for the operation leading to the new deployment.

[0020] Also provided, according to one aspect, is a data processing system comprising the module mentioned.

[0021] In one example, the system is non-uniform memory access, NUMA.

[0022] Most of the data processing systems currently available are mul Tiprocessors, have memory distributed among the processors and have the characteristic of non-uniform memory access from processors to data stored in memory.

[0023] In one example, the system further comprises an orchestrator configured to request identification of the destination resource by the module and direct the operation resulting in the new deployment of the service.

[0024] In one example, the system further comprises a manager configured to manage the set of resources and update the data topology in conjunction with the module.

[0025] By integrating not only the module, but also the orchestrator and the manager, a complete architecture is obtained to ensure in a coordinated manner the implementation of the new deployment with optimized routing in the data processing system, such as a NUMA system.

[0026] Also provided, in one aspect, is a method implemented by a module in a cloud computing environment, the module being adapted to operate on a data processing system comprising a set of resources, the set of resources comprising a source resource involved for an initial deployment of a service, the method comprising: evaluating, within the set of resources, a potential resource for a new deployment of the service using an affinity function taking into account at least one constraint relating to a topology of data associated with the service and / or to an architecture of the data processing system, and when an evaluation result of a potential resource is favorable, identify the potential resource as a destination resource for an implementation of a cloning operation resulting in the new deployment of the service.

[0027] Also provided, according to one aspect, is a computer program comprising instructions which, when the program is implemented by a processor, result in implementing the method discussed. Brief description of the drawings

[0028] Other characteristics, details and advantages will appear on reading the detailed description below, and on analyzing the attached drawings, in which: Fig.l

[0029] [Fig.l] illustrates a resource management and cloning process according to an exemplary embodiment. Fig. 2

[0030] [Fig.2] represents an initial state of a system comprising two clusters before the implementation implementing a cloning process. Fig. 3

[0031] [Fig.3] represents an example of the final state of the system of [Fig.2] after the implementation of a cloning process, reflecting changes in the clusters. Fig. 4 Fig. 5

[0032] [Fig.4] and [Fig.5] each represent another example of the final state of the system of [Fig.2] after implementing a different cloning process, reflecting different changes in the clusters. Description of the embodiments

[0033] In the following description, identical reference numerals designate identical elements or elements having similar functions.

[0034] The present disclosure relates to a technique for facilitating service management in a cloud computing environment, specifically in telecommunications systems.

[0035] It should be noted as a preamble that the term "service" is used in this document generally to encompass a service itself, one or more microservices or even a complete application. An "application" is understood to mean a set of software functionalities that meet a specific need. An application may be composed of one or more services or microservices that work together to provide the overall functionality. It should be noted that the distinction between a "service" and a "microservice" is based primarily on the scale and functional breakdown of the software architecture of an application. A service is a self-contained functional unit that can cover a broad set of functionalities and that can equally well form part of a larger application or be used by several applications.A microservice is smaller and is usually responsible for a specific functionality of an application.

[0036] The proposed technique thus makes it possible to assist a cloning system in order to replicate configurations supporting services deployed in a cloud computing environment, specifically in telecommunications systems. Cloning can be part of a migration approach, involving not only a new deployment of a service, but also a deletion of the initial deployment of the service, so as, for example, to ensure continuity of service in anticipation of maintenance involving taking a server offline. Cloning can also be part of an approach to instantiating a service in order to offer better performance to an increasing number of users.

[0037] For reference, an example of a suitable cloning system is detailed in the patent application FR2306267. Such a cloning system includes in particular a manager, an orchestrator and, optionally, a virtual service configured as a routing device.

[0038] The manager plays a key role in triggering the cloning process of a configuration supporting a service. It is capable of detecting a triggering event resulting from the application of a service management strategy. Following the detection of this event, the manager defines one or more constraints associated with the event and sends cloning instructions to the orchestrator.

[0039] The orchestrator, in the cloud computing environment, is designed to receive from the manager one or more cloning instructions and said one or more constraints. The orchestrator is also capable of collecting one or more information on the use of individual resources from various data processing agglomerations. This or these information are obtained with sufficient granularity to allow a detailed analysis of the use of each individual resource. The interpretation of the instruction(s) by the orchestrator allows it to designate one or more resources defining an initial deployment of a service within an initial communication infrastructure (or initial working environment).Taking into account the cloning instruction(s), the received constraint, and the gathered information(s), the orchestrator can then identify one or more target resources in the same communication infrastructure, possibly in the same cluster, or in at least one new communication infrastructure. This allows cloning of the designated resource(s), thus facilitating a new deployment of the service that meets the specified constraint(s).

[0040] The virtual service configured as a routing device may be configured to redirect, upon completion of a cloning operation, all or part of network traffic from the initial deployment of the service concerned to the new deployment, in a manner transparent to the orchestrator and the manager. This allows for a smooth and efficient transition between the initial deployment and the new deployment, thus contributing to service continuity.

[0041] In addition to the above description of the cloning system, all the details contained in patent application FR2306267 and defining more precisely the cloning system or its operating principle for implementing cloning operations can be applied in an identical manner to the cloning system and the cloning operations described in this document, unless otherwise specified.

[0042] One aspect of the technique proposed in this document is a module adapted to operate on a data processing system comprising a set of resources, including a resource defining an initial deployment of a service. The The resource defining the initial deployment of the service in question is called the “source resource” in the context of a cloning operation.

[0043] Any suitable hardware and / or software means may be used for the practical implementation of the module. Generally, although aspects of the proposed technique may be described herein as a process, a device, a system, a procedure or a method, it should be noted that the proposed technique may also cover a computer memory capable of being connected to a processor possibly connected to a communication interface, the memory storing instructions which, when executed by such a processor, make it possible to carry out the processes, devices, systems, procedures or methods described herein.

[0044] It is understood that, in the context of assisting a cloning operation, the module may be integrated into the cloning system described above and / or may be configured to communicate with the cloning system so as to facilitate the identification by the orchestrator of one or more target resources.

[0045] Some terms specific to data processing systems and cloud computing environments are now clarified for a better understanding of the proposed technique.

[0046] The term "data processing system" refers to a physical and software medium that enables communication and sharing of resources and services in the cloud computing environment. This system may refer to a communication infrastructure or one or more of its subparts, including data processing and storage systems, servers and networks, data centers, cloud systems, telecommunications equipment, etc. It may also relate to the communication infrastructure within a specific organization, such as an internal network of computers and servers, or to a broader infrastructure, such as a telecommunications network or the cloud. The proposed technique is applicable to any type of data processing system.

[0047] Nowadays, most data processing systems have a multiprocessor architecture. Access to memory greatly influences the performance and the way of programming such architectures. Two main classes of multiprocessor architectures are distinguished depending on the way in which the processors access the memory, namely symmetric access architectures and non-uniform access architectures. Non-uniform memory access systems, also called NUMA systems in the art, have advantages in terms of the speed of data flows between processors and memory areas. A NUMA system is a system with a multiprocessor architecture comprising several separate memory areas placed in different locations and on different buses connected to the same interconnection network. A co The main benefit of this memory distribution is that it facilitates concurrent access by different processors. A particularity of a NUMA system is that, for each processor, access times differ depending on the memory area accessed.

[0048] In the context of a NUMA system, a "node" or "NUMA node" designates a set formed by a memory area, a processor and a communication interface, all located on the same bus. A "distance" represents a number of hops from one node to another to implement a particular task within the framework of the implementation of a service.

[0049] A data processing system comprises a set of resources that can be reserved for the purpose of operating one or more services. This set of resources may include resources of various types, in particular calculation times at the level of one or more processors, locations of one or more memories, or even usage slots, expressed for example in time and / or frequency, of one or more communication channels.

[0050] Cloud computing environments rely on one or more data processing systems as defined above.

[0051] In these environments, the basic hosting unit is often called a "container." These containers are lightweight software units that encapsulate the code and all of its dependencies, thereby allowing an application to run reliably from one computing environment to another.

[0052] For the management of these containers, a solution called Kubernetes, K8S, is frequently used. Kubernetes is a system that facilitates the deployment, scaling and management of containerized applications.

[0053] In the Kubernetes architecture, containers are grouped into "pods," which are the basic unit representing a deployment of an application. Multiple pods can be grouped into a "Node," which symbolizes a server. The definition of "Node" in the Kubernetes architecture corresponds to that of "node" in the NUMA system. These nodes are then grouped into "clusters," which are sets of servers that work together and can be seen as a single system.

[0054] In the context of Kubernetes, a cluster consists of a group of "Masters" and Nodes. Masters are the components of the Kubernetes cluster that provide the control interface for the cluster, and manage pod scheduling, failure detection and management, and deployment of new versions of applications. Nodes, on the other hand, are the servers that run the applications and provide the runtime environment for the containers.

[0055] To manage network communications between the containers of an application deployed on a Kubernetes cluster, auxiliary containers, called “sidecar proxies” are attached to each application's main container. Sidecar proxies are responsible for intercepting and managing network communications. Each sidecar proxy acts as an intermediary between the main container it is attached to and the rest of the network. To enhance security, sidecar proxies can include functions such as request and response validation, authorization and identity management, and monitoring and alerting on anomalies.

[0056] ISTIO is an example of an open source service mesh, commonly used by networking and security operators for running distributed microservices-based applications, and which provides a uniform way to connect, manage and secure these microservices using sidecar proxies.

[0057] The proposed technique makes it possible to facilitate the implementation of cloning operations by a cloning system as described above. For this purpose, it is possible, for example, to define an initial state of the data processing system at an initial time before an implementation of a cloning operation relating to a service and a final state of the data processing system at a final time after the implementation of the cloning operation. At the initial time, the data processing system is configured such that one or more resources from the set of resources intervene for an initial deployment of the service, this or these resources are referred to as source resources.At the final instant, the data processing system is configured in such a way that one or more resources from the set of resources, different from the source resource(s), intervene for a new deployment of the service, this or these resources are qualified as destination resources.

[0058] As an illustration, patent application FR2306267 provides a procedure for identifying destination resources, for the implementation of cloning, according to a resource-aware policy. But this policy does not take into account the affinity between processes and data, which is now at the heart of the search for performance, in particular in the management of NUMA systems. A particular example of an application domain where the affinity between processes and data is crucial is the placement of micro-services in a 5G telecommunications system.

[0059] The technique proposed in this document provides a robust procedure for determining, within the resource set, one or more suitable destination resources from a larger set of potential resources. This procedure is particularly suitable in areas where process and data affinity is an important performance factor.

[0060] For this purpose, the module is configured to evaluate, within the set of resources, at least one potential resource for a deployment of a service using an affinity function.

[0061] The result of the evaluation may be favorable or unfavorable and may concern a single potential resource or a group of potential resources evaluated simultaneously. The module may also be configured to evaluate several resources or groups of potential resources successively, in which case a separate evaluation result is obtained for each evaluation.

[0062] The module is also configured to identify one or more potential resources having a favorable evaluation result as resources attributable to the deployment of the service. Conversely, the module is also configured not to identify, where appropriate, one or more potential resources having an unfavorable evaluation result as resources attributable to the deployment of the service. A resource identified as attributable to the service is a destination resource for the implementation of a cloning operation resulting in the new deployment of the service, while a resource identified as not attributable to the service is not such a destination resource.

[0063] The affinity function is at the heart of the proposed technique. It determines how resources are evaluated based on various criteria or constraints in a cloning process.

[0064] The affinity function takes into account at least one constraint. However, it has the capacity to take into account a multitude of constraints, which may relate either to the topology of the data associated with the service, or to the architecture of the processing system, or to a combination of the two. By potentially taking into account a variety of constraints, the application of the affinity function contributes to optimal management of resources, making it possible to offer, for example, increased performance and / or security for the end user.

[0065] To define the nature of the constraints, which can also be called criteria, it is also necessary to define what is meant by "data topology" and by "processing system architecture".

[0066] In the context of the proposed technique, data topology does not refer to the topology of the underlying computer network. Rather, it relates to information about the neighborhood of data associated with the same service. These data may have interactions with each other or with different entities in the network, including memories and processors. The interactions may include function calls, data requests, or other forms of communication.

[0067] The constraints related to the data topology may include isolation constraints, i.e. ensuring that certain data remain isolated from others, and security constraints, i.e. ensuring that access to the data is unauthorized or authorized based on certain criteria or even that access to the data is prohibited.

[0068] The architecture of the processing system can be physical or logical. It defines the connections between network entities and their possible hierarchy. The physical architecture or topology of the processing system is a spatial representation of the processing system. In the case of a NUMA system, it is the way in which the nodes that compose it are interconnected. Classic topologies include bus, ring, star, or mesh topologies. Also in the case of a NUMA system, the logical architecture or topology defines how data travels along the communication lines connecting the nodes.

[0069] Architecture constraints include constraints such as cost, i.e., the economic evaluation of using one resource over another, access potential, i.e., the ease with which a resource can be accessed, geographic location, i.e., the physical location of a resource, and non-overlap.

[0070] The non-overlap constraint, when applied to a NUMA architecture, ensures that resources do not overlap or are not superimposed in the same memory area. The NUMA node non-overlap constraint can be specifically Boolean.

[0071] Constraints related to the data topology and the architecture of the processing system may also be cited. This includes constraints on latency, i.e. the time required to access data, bandwidth, i.e. the amount of data that can be transmitted in a given time, load, i.e. the amount of work or requests that a resource can handle), computing performance, i.e. the speed at which an operation can be executed), or energy performance, i.e. the amount of energy consumed to perform an operation).

[0072] Now, we will describe a particular mode of implementation of the proposed technique, in connection with a cloning process, in the context of a NUMA system and a Kubemetes platform.

[0073] It goes without saying that a person skilled in the art is capable of transposing the embodiments set out in this document into the context of any other operation involving the allocation of a resource of any data processing system and using any container management platform.

[0074] Two modes of triggering cloning are envisaged: the “orchestrator” mode and the “proxy” mode.

[0075] The main difference between the “orchestrator” mode and the “proxy” mode lies in the way in which the cloning is triggered and the dynamics of reaction to the state of the resources.

[0076] In the “orchestrator” mode, the triggering of cloning is mainly controlled by a central orchestrator which is based on user preferences and Policy rules defined by the telecom operator. These preferences and rules are defined in advance, and the orchestrator uses this information to manage resources and trigger the cloning process. Actions are therefore largely predetermined and depend on the planning and strategy defined by the operator's rules.

[0077] This mode provides particularly predictable resource management, as actions are based on established rules and preferences. It is best suited to stable environments where resource demands are predictable and operator policy is well defined.

[0078] In "proxy" mode, the cloning process is triggered in response to internal node events, which may be related to reaching or exceeding a predetermined threshold in resource usage. Thus, cloning is triggered more dynamically, in response to the actual state of the resources. Sidecar proxies play an active role in detecting events and passing information to the orchestrator.

[0079] This mode provides more dynamic and reactive resource management, as actions are based on the current state of resources and defined thresholds.

[0080] It is more suitable for dynamic and uncertain environments, where resource utilization may vary rapidly or unpredictably.

[0081] It is important to note that the choice between “orchestrator” mode and “proxy” mode will depend on the specific environment, operator requirements and workload characteristics. In some cases, a combination of both modes may be used to take advantage of the benefits of each.

[0082] [Fig. 1] illustrates a resource management and cloning process according to the “orchestrator” mode.

[0083] User preferences and telecom operator policy rules are established at block (102) by business support systems or operations support systems, called "Business Support Systems / Operations Support Systems", BSS / OSS, in English. Such computer systems are used by telecom operators to manage their networks. The telecom operator policy may relate to different aspects, including load sharing and / or resilience.

[0084] In the “orchestrator” mode, the manager can apply the preferences and / or rules established at the block (102) by sending service requests, i.e. instructions, to the orchestrator which executes them and thus triggers a cloning process.

[0085] In block (104), the available resources are checked. This action is performed by a platform, called "Cloud Gateway", CG, in English, which facilitates secure access to cloud services and by the orchestrator, as a system which manages the execution and interaction between tasks and services.

[0086] At block (106), the orchestrator determines whether or not the available resources allow the received service requests to be applied. If not, due to a lack of available resources as disclosed at block (104), no cloning is implemented.

[0087] When the available resources are sufficient to allow the application of the service requests, the resources to be cloned are identified at block (108). These may be entire clusters, worker nodes, pods, applications, etc.

[0088] The affinity function is implemented (110) in order to evaluate potential resources, i.e. all or part of the available resources, and to identify destination resources within these potential resources.

[0089] Depending on the results of the evaluations of the potential resources, destination resources are identified in block (112). The destination resources are intended to host the clones of the resources identified in block (108). These resources are likely to include nodes performing various processing tasks, called “Processing Node”, PN, nodes performing more particularly processing tasks related to the operation of the network, called “Network Processing Node”, NPN, in English, as well as terminals or user equipment, called “User Equipment”, UE, in English.

[0090] The implementation of the affinity function can for example be done at two distinct levels, that is to say on the one hand at a global level, that is to say carried out at the scale of the data processing system or network as a whole, and on the other hand at a local level, that is to say within a specific cluster.

[0091] Implementing the affinity function at a global level involves taking into account several clusters, each of which could contain potential resources. The clusters are evaluated according to one or more specific constraints relating, for example, to the service concerned by the cloning operation.

[0092] This may be, for example, latency or bandwidth, which can directly impact the user experience. For example, a customer wishing to deploy a real-time application via the data processing system could require that the latency does not exceed a certain threshold. At this level, the affinity function makes it possible to evaluate each cluster with respect to this or these constraints. The evaluation result of a given cluster determines whether this given cluster, as a whole, is capable or not of meeting this or these needs.

[0093] Once a particular cluster has been identified as suitable at the global level, the affinity function can come into play a second time at a finer scale, i.e. within the cluster itself. This granular evaluation makes it possible to select, among the nodes or resources of the cluster, those which best correspond to the specific needs of the service to be deployed. Here, constraints such as the per computational formance, data isolation or even the constraint of non-overlapping NUMA nodes are particularly relevant.

[0094] To illustrate, consider a service that requires intensive but isolated computations. In a cluster, some nodes may share their memory (overlapping NUMA nodes). The non-overlapping constraint ensures that the selected nodes do not have overlap, thus ensuring efficient use of resources and preventing potential bottlenecks or interference. The major technical advantage here is to optimize performance and ensure smooth execution of the service in question.

[0095] In sum, this dual application of the affinity function, both at the global and local level, ensures not only that the chosen cluster is suitable as a whole, but also that the specific resources within that cluster are most appropriate for the task at hand. This results in better performance, better resource management, and increased satisfaction of specific customer or service needs.

[0096] Alternatively, it is possible, in some cases, to implement the affinity function at a single level. For example, the cluster containing one or more source resources may also contain one or more potential resources and provision may be made to first evaluate this or these potential resources at the local level and, in case of a positive evaluation result, to identify the corresponding potential resource(s) as destination resources without also implementing the affinity function at the global level and / or at the local level of other clusters.

[0097] One advantage of this approach is related to the operation of the Kubernetes platform, where each cluster has its own control plane, i.e. its own local controller. The process of implementing the affinity function is relatively simple in the case where one or more source resources and one or more potential resources to be evaluated belong to the same cluster and are already all known to the local controller. Another advantage of this approach is that, when the initial resources and those used for the new deployment are in the same cluster, the synchronization and transmission of data between them is generally faster and more efficient. This facilitates and accelerates the cloning process, since the data does not need to cross cluster boundaries or face possible external network latencies.

[0098] When a potential resource and a source resource are in separate clusters, the process of implementing the affinity function at the local level is a little more complex. The local controller of the cluster containing the source resource, or a central entity such as the orchestrator or manager, notifies the local controller of the cluster containing the potential resource to be evaluated by providing a list of constraints to be considered. The local controller of the cluster containing the potential resource to be evaluated uses the affinity function to evaluate the potential resource according to the provided constraints. An evaluation confirmation can then be transmitted to the local controller of the cluster containing the source resource and / or to a central entity such as the orchestrator or manager. The evaluation confirmation can include the evaluation result of the potential resource.

[0099] A concrete example of applying an affinity function to evaluate a potential resource at a local level is now described using two example constraints: the latency constraint and the non-overlapping constraint, assuming that a container needs low latency to operate efficiently and that it should not be overlapped with other containers in the same NUMA node.

[0100] Latency is the time it takes for data to be transferred from one point to another. In the context of a NUMA data processing system, this can, for example, refer to the latency between different nodes. For this example, assume that latency has three possible groups of values, measured in microseconds (ps): low when less than lOps, medium when between lOps and 50ps, and high when greater than 50ps.

[0101] The non-overlap constraint ensures that resources do not overlap or are not superimposed in the same memory area. Two possible Boolean values ​​can be chosen by convention, for example "True" when no overlap is allowed and "False" when overlap is allowed, or vice versa.

[0102] Applying the affinity function to evaluate a potential resource may include a latency evaluation with assignment of a first separate score depending on whether the latency is low, medium, or high, a non-overlap evaluation with assignment of a second separate score depending on whether overlap is possible, and an overall evaluation of the potential resource combining the first and second scores to obtain a total score as an evaluation result.

[0103] As examples, four possible evaluation results are detailed in a scenario where one wishes to deploy a container in one of four corresponding potential resources named A, B, C and D.

[0104] Resource A: Low latency (<10ps) + No overlap = High total score.

[0105] Resource B: Average Latency (25ps) + No Overlap = Total Score AVERAGE.

[0106] Resource C: Low latency (<10ps) + Possibility of overlap = Average total score.

[0107] Resource D: High latency (60ps) + Possibility of overlap = Low total score.

[0108] In this example, resource A would thus be the most appropriate to deploy the container in question due to its low latency and lack of overlap. This is a simplified example to illustrate the concept. In a real environment, many other factors and constraints could be considered to determine the best resource to deploy a container or set of containers.

[0109] At block (114), cloning is performed.

[0110] At block (116), the data topology is updated. At block (118), the service routing information is updated. The updates made at blocks (116) and (118) involve transmitting one or more update messages to various entities.

[0111] In particular, a memory manager may be configured to generate and transmit data topology update messages.

[0112] Memory Manager is a feature of Kubernetes that aims to improve the performance of services that require specific memory resources for optimal operation, especially in environments where memory resources are fragmented or limited. It contributes to efficient memory management on nodes in performance-critical scenarios, especially in scenarios using a NUMA data processing system.

[0113] It may be provided, for example, that the memory manager transmits an update message containing information on new hardware configurations due to cloning to a system for managing the hardware components of the data processing system, such as nodes ensuring data processing or disks ensuring data storage. This system can then update the hardware configuration of the data processing system.

[0114] For example, the memory manager may transmit an update message containing the new pod instances created during cloning to a virtualized network function orchestrator. The virtualized network function orchestrator may then update its list of active instances accordingly, to ensure more accurate management of the lifecycle of the virtualized network functions.

[0115] It may be provided, for example, that the memory manager transmits an update message containing new links following cloning or modifications following cloning of links pre-existing to cloning to a programmable network controller and / or to a virtualized network functions infrastructure. These entities can then update their topologies to participate in better traffic management.

[0116] It may be provided, for example, that the memory manager transmits a message update message relating to new states of the data processing system following cloning to the Business Support Systems and / or Operations Support System (BSS / OSS), to enable synchronization of operational and business information with the current states of the data processing system and thus contribute to better visibility and improved management of resources and clients. Alternatively, this update message may also be transmitted by the hardware component management system of the data processing system after the latter has itself received an update message from the memory manager and updated the hardware configuration of the data processing system accordingly.

[0117] The tasks of blocks (114) to (118) can be implemented by Kubernetes or by ISTIO. Regardless of the triggering mode chosen, cloning makes it possible to simplify and secure access to the functions or microservices forming a given application or a given service, by reproducing the data access logic and the associated security.

[0118] In the "proxy" mode, sidecar proxies play a crucial role in triggering a cloning operation. Unlike the "orchestrator" mode, which triggers cloning based on predetermined instructions, the "proxy" mode dynamically responds to the internal conditions of each node. Thus, cloning triggered through the "proxy" mode allows for better adaptability and responsiveness to the internal conditions of the nodes.

[0119] To clarify, resource usage thresholds are established for each node, taking into account various factors such as the number of requests per second, the size of the requests, energy consumption and RAM usage. When one of these thresholds is reached or exceeded, an event is triggered at the level of the affected container.

[0120] Information from this event can then be passed to the orchestrator by the container's sidecar proxy. This can also be relayed to the manager. The orchestrator and / or manager then use these events to determine the appropriate actions to take, potentially including a cloning process similar to that of the "orchestrator" mode as reflected in blocks (112) to (118) of [Fig.l]. Here, so-called "source" sidecar proxies play a dual role: they detect events at the source nodes and can request the orchestrator to trigger cloning. The source sidecar proxies can also trigger cloning themselves and then inform the orchestrator.

[0121] Upon receipt of the information from the source sidecar proxies, the orchestrator can then designate destination resources either itself or following a dialogue with another orchestrator or with other sidecar proxies known as "sidecar proxies". tination", which are associated with the resources that will host the clones of the services and / or configurations. The cloning is then performed and the service routing information is updated in the same way as indicated in blocks (14) to (18) of [Fig.l]. To facilitate communication during this process, new communication channels are set up, for example by the orchestrator, between the source and destination sidecar proxies, as well as between the source sidecar proxies and the masters associated with the destination resources. The orchestrator serves as a pivot in this complex network, associating each source and destination sidecar proxy with a group of identified resources hosting the services or applications concerned by the cloning. This association can notably be based on the use of decentralized identifiers, known as "Decentralized IDs", DIDs, in English.

[0122] [Fig.2] schematically illustrates two Kubernetes clusters (200, 300).

[0123] Each cluster is composed of a group of Masters and several nodes.

[0124] The group of Masters forms a control plan responsible for the management and coordination of the different elements of the cluster.

[0125] In particular, the control plane comprises control modules ("Controllers") responsible for monitoring the state of the cluster and performing actions to maintain, or achieve, the desired state. For example, there are command modules to manage deployments, services, replicas, among others. A Controller Manager is responsible for executing these command modules.

[0126] Other components of the control plane play specific roles.

[0127] An API Server is provided to expose the Kubernetes API and serves as the main entry point for interacting with the cluster. A Load Balancer is used to distribute the load of incoming traffic to different services by distributing traffic between cluster nodes or between pods running on different nodes. A Scheduler is responsible for assigning pods to cluster nodes based on defined resource requirements, constraints, and policies. A database called ETCD stores the state of the Kubernetes cluster in real time, including information about nodes, pods, services, configurations, etc. It makes this information readable and writable by all cluster components in real time.

[0128] It is considered that at a given instant, the entire control plane of a given cluster (200, 300), or at least one of its components, such as the control module manager, a specific control module, the API server, the load balancer, or the scheduler, plays the role of an orchestrator (202, 302) implementing a cloning procedure.

[0129] Each cluster also comprises several nodes (210, 220, 230, 310, 320, 330) which themselves contain pods. Each pod corresponds to the deployment of an application, the related workload of which is represented by a cube. Certain pods of interest, corresponding to specific application deployments, are also represented with sidecar proxies.

[0130] [Fig.3] represents a final state of one of the clusters (200) of [Fig.2] at the end of a cloning procedure of a pod, in an exemplary embodiment. The orchestrator (202) first identified a first pod (212) located in a first node (210) of the cluster (200) as the original resource. The orchestrator then designated a second pod (222) located in a second node (220) of this same cluster (200) as the destination resource. After this, the cloning procedure was implemented, replicating the first pod (212) in the second pod (222).

[0131] [Fig.4] represents another final state of one of the clusters (200) of [Fig.2] at the end of a cloning procedure of a node, in another exemplary embodiment. The orchestrator (202) first identified a first node (220) of the cluster (200) as the original resource. The orchestrator then designated a second node (230) of this same cluster (200) as the destination resource. After this, the cloning procedure was implemented, replicating the pods of the first node (220) in the second node (230).

[0132] [Fig.5] shows another final state of the clusters (200, 300) of [Fig.2] after a node cloning procedure, in another exemplary embodiment. The orchestrator (202) located in a first cluster (200) has first identified, in the first cluster (200), a node to be cloned (210), as a source resource. It can be assumed here that the orchestrator (202) was not able to identify a destination node in the first cluster. Potential reasons may include obtaining one or more unfavorable evaluation results following the implementation of an affinity function at a global level to evaluate the first cluster as a whole or at a local level to evaluate one or more specific nodes as potential resources of the first cluster in case of implementation at a local level.

[0133] The orchestrator (202) then communicated with another orchestrator (302) located in a second cluster (300), notifying it of specific constraints for the implementation, at the local level of the second cluster, of an affinity function taking into account these notified constraints. Following the obtaining of a favorable evaluation result, it is assumed that a second node (330) has been successfully identified in the second cluster as a destination resource. After this, the cloning procedure has been implemented, replicating the first node (210) in the second node (330).

[0134] The procedure thus developed in connection with [Fig.5] for the replication of a node from a first cluster to a second cluster can obviously be applied in a similar way to the replication of several nodes, or to the replication of a pod, or even to the replication of several pods belonging or not initially to the same source node.

[0135] The proposed technique can be applied in a wide variety of environments, including the management of distributed computing systems, the deployment of radio access networks in telecommunications systems, and the deployment of distributed configurations across multiple sites, with multiple actors and zones, and possibly replicas distributed across multiple data centers, such configurations being capable of supporting varied functional sets.

[0136] Regardless of the specific working environment of the resource to be evaluated - whether it is a single node, a set of servers, a specific geographical area or an IP subnet - the proposed technique is designed to adapt to these different contexts.

[0137] Although the proposed technique has been described in detail with reference to certain preferred embodiments, various modifications and variations may be made without departing from the scope of the invention as defined in the appended claims. For example, the described procedures may be performed in a different order, elements may be added or deleted, and features of different embodiments may be combined as appropriate.

Claims

Claims

1. A module in a cloud computing environment, the module being adapted to operate on a data processing system comprising a set of resources (210, 212, 220, 230, 310, 320, 330), the set of resources comprising a source resource (212, 220) acting for an initial deployment of a service, the module being configured to: evaluate (110), within the set of resources, at least one potential resource (210, 212, 220, 230, 310, 320, 330) for a new deployment of the service using an affinity function taking into account at least one constraint relating to a topology of data associated with the service and / or to an architecture of the data processing system, and when an evaluation result of a potential resource is favorable, identify (112) the potential resource as a destination resource for an implementation of a cloning operation resulting in the new deployment of the service.

2. The module of claim 1, further configured to update the data topology in connection with the new deployment of the service.

3. Module according to claim 2, further configured to transmit an update message concerning the updated data topology and / or a configuration of the new deployment of the service to at least one third-party module.

4. The module of claim 2 or 3, further configured to collaborate with an orchestrator to update a routing in accordance with the updated data topology and the new deployment of the service following the cloning operation.

5. Module according to one of claims 1 to 4, in which the topology of the data provides information on a neighborhood of each data item currently associated with the service.

6. Module according to one of claims 1 to 5, wherein said at least one constraint comprises at least one constraint among a latency constraint, a bandwidth constraint, a load constraint, a cost constraint, an isolation constraint, a security constraint, an access potential constraint, a constraint of geographical location of the potential resource and a constraint of non-overlap of the destination resource and a memory resource of the data processing system.

7. Data processing system comprising a module according to one of claims 1 to 6.

8. The system of claim 7, wherein the system is non-uniform memory access, NUMA.

9. The system of claim 7 or 8, comprising an orchestrator configured to request identification of the destination resource by the module and direct the cloning operation.

10. System according to one of claims 7 to 9, further comprising a manager configured to manage the set of resources and update the topology of the data in connection with the module.

11. A method implemented by a module in a cloud computing environment, the module being adapted to operate on a data processing system, comprising a set of resources (210, 212, 220, 230, 310, 320, 330), the set of resources comprising a source resource (212, 220) acting for an initial deployment of a service, the method comprising: evaluating (110), within the set of resources, at least one potential resource (210, 212, 220, 230, 310, 320, 330) for a new deployment of the service using an affinity function taking into account at least one constraint relating to a topology of data associated with the service and / or to an architecture of the data processing system, and when an evaluation result of a potential resource is favorable, identifying (112) the potential resource as a destination resource for the implementation of a cloning operation resulting in the new deployment of the service.

12. A computer program comprising instructions which, when the program is implemented by a processor, result in implementing the method according to claim 11.

Images