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

Abstract

The invention proposes a module in a cloud computing environment, the module being designed 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) involved in 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 that takes into account at least one constraint relating to a topology of data associated with the service and / or an architecture of the data processing system and, when a result of evaluating a potential resource is favourable, identify (112) the potential resource as a destination resource for an implementation of a cloning operation resulting in the new deployment of the service.

Description

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

[0001] This 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.

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

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

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

[0006] Furthermore, they also do not provide an appropriate 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 comprising a source resource involved in an initial deployment of a service, the module being configured to: evaluate, 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.

[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 relation to the new service deployment.

[0011] This refresh 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 route according to 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 about a neighborhood of each data item commonly associated with the service.

[0017] This provides 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 discussed module.

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

[0022] Most data processing systems currently available are multiprocessor, 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 includes an orchestrator configured to request identification of the destination resource by the module and direct the operation resulting in the re-deployment of the service.

[0024] In one example, the system further includes a manager configured to manage the resource set 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] There is also provided, according to one aspect, 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, identifying 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, in one aspect, is a computer program comprising instructions which, when the program is implemented by a processor, result in implementing the method discussed.

[0028] Other features, details and advantages will become apparent upon reading the detailed description below, and upon analyzing the attached drawings, in which: Fig. 1

[0029] illustrates a resource management and cloning process according to an example implementation. Fig. 2

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

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

[0032] and each represent a different example of the final state of the system after implementing a different cloning process, reflecting different changes in the clusters.

[0033] In the following description, like 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 in a general way to encompass a service itself, one or more microservices, or even a complete application. An "application" is understood to be a set of software functionalities that meet a specific need. An application can 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 mainly based on the scale and functional division of an application's software architecture. A service is a self-contained functional unit that can cover a broad set of functionalities and can either form part of a larger application or be used by several applications. A microservice is smaller and is generally 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 to, for example, ensure continuity of service in anticipation of maintenance involving taking a server offline. Cloning can also be part of an approach to instantiate 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 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 policy. 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 can be configured to redirect, after a cloning operation, all or part of the network traffic from the initial deployment of the affected service to the new deployment, transparently for 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 details contained in patent application FR2306267 and defining more precisely the cloning system or its operating principle for implementing cloning operations may apply identically 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 resource defining the initial deployment of the service under consideration is called a "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 in this document 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 in this document.

[0044] It is understood that, in the context of assisting a cloning operation, the module may be integrated with the cloning system described above and / or may be configured to communicate with the cloning system in such a way 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 refer 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 such architectures are programmed. There are two main classes of multiprocessor architectures depending on how the processors access memory, namely symmetric access architectures and non-uniform access architectures. Non-uniform memory access systems, also called NUMA systems in the art, offer advantages in terms of 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 corollary of this memory distribution is a facilitation of concurrent access by the different processors.A particularity of a NUMA system is that, with respect to each processor, access times differ depending on the memory area accessed.

[0048] In the context of a NUMA system, a "node" or "NUMA node" refers to a set of memory, a processor, and a communication interface, all located on a single bus. A "distance" represents the number of hops from one node to another to perform a particular task within the framework of implementing 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 computing 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 its dependencies, allowing an application to run reliably from one computing environment to another.

[0052] To manage 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 an application deployment. 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 thought of 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 applications and provide the runtime environment for containers.

[0055] To manage network communications between containers in an application deployed on a Kubernetes cluster, auxiliary containers, known as sidecar proxies, are attached to each of the application's main containers. 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 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 such 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, particularly 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 paper 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-data affinity is an important performance factor.

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

[0061] The evaluation result can be favorable or unfavorable and can concern a single potential resource or a group of potential resources evaluated simultaneously. The module can 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, if applicable, 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 ability 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 both. By potentially taking into account a variety of constraints, the application of the affinity function contributes to optimal resource management, 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 "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 concerns information about the neighborhood of data associated with the same service. These data may have interactions with each other or with different network entities, including memories and processors. Interactions may include function calls, data queries, or other forms of communication.

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

[0068] The architecture of the processing system can be physical or logical. It defines the connections between the 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 refers to 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] There are also constraints related to data topology and the architecture of the processing system. These include constraints on latency, i.e. the time required to access a piece of 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 Kubernetes 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 considered: “orchestrator” mode and “proxy” mode.

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

[0076] In the "orchestrator" mode, cloning initiation is primarily controlled by a central orchestrator 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 for 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 resource utilization threshold. This way, cloning is triggered more dynamically, in response to the actual resource status. Sidecar proxies play an active role in detecting events and passing information to the orchestrator.

[0079] This mode provides more dynamic and responsive resource management, as actions are based on the current resource status and defined thresholds.

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

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

[0082] illustrates a resource management and cloning process in “orchestrator” mode.

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

[0084] In the "orchestrator" mode, the manager can apply the preferences and / or rules established in 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 that 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 revealed at block (104), no cloning is implemented.

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

[0088] The affinity function is implemented (110) 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, i.e. on the one hand at a global level, i.e. carried out at the scale of the data processing system or network as a whole, and on the other hand at a local level, i.e. within a specific cluster.

[0091] Implementing the affinity function at a global level involves considering multiple clusters, each of which could contain potential resources. Clusters are evaluated based on one or more specific constraints, such as the service being cloned.

[0092] Examples include 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 might require that latency not exceed a certain threshold. At this level, the affinity function allows each cluster to be evaluated against this or these constraints. The evaluation result for a given cluster determines whether or not this given cluster, as a whole, is capable 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 that best match the specific needs of the service to be deployed. Here, constraints such as computing performance, data isolation, or the constraint of non-overlapping NUMA nodes are particularly relevant.

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

[0095] In short, this dual application of the affinity function, both at the global and local levels, 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. The result is 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 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 sent 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-overlap 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 (µs): low when less than 10µs, medium when between 10µs and 50µs, and high when greater than 50µs.

[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 based on whether the latency is low, medium, or high, a non-overlap evaluation with assignment of a second separate score based 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 outcomes 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 (<10µs) + No overlap = High total score.

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

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

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

[0108] In this example, resource A would be the most appropriate resource 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-world environment, many other factors and constraints could be considered to determine the best resource to deploy a container or set of containers.

[0109] In 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 can be configured to generate and transmit data topology update messages.

[0112] Memory Manager is a Kubernetes feature 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 helps to efficiently manage memory on nodes in performance-critical scenarios, especially in scenarios using a NUMA data processing system.

[0113] For example, it may be provided 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 can be configured to transmit an update message containing the new pod instances created during cloning to a virtualized network functions orchestrator. The virtualized network functions orchestrator can then update its list of active instances accordingly, to provide more accurate management of the virtualized network functions lifecycle.

[0115] For example, the memory manager may transmit 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 a virtualized network functions infrastructure. These entities can then update their topologies to participate in better traffic management.

[0116] For example, it may be provided that the memory manager transmits an update message relating to new states of the data processing system following cloning to the business support systems and / or the 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 system for managing the hardware components 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 in blocks (114) to (118) can be implemented by Kubernetes or by ISTIO. Regardless of the triggering mode chosen, cloning simplifies and secures 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 proxy mode, sidecar proxies play a crucial role in triggering a cloning operation. Unlike orchestrator mode, which triggers cloning based on predetermined instructions, proxy mode dynamically responds to the internal conditions of each node. Thus, cloning triggered through proxy mode allows for greater adaptability and responsiveness to internal node conditions.

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

[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). Here, so-called "source" sidecar proxies play a dual role: they detect events at the source nodes and can request the orchestrator to trigger the cloning. The source sidecar proxies can also trigger the cloning themselves and then inform the orchestrator.

[0121] Upon receiving 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 so-called "destination" sidecar proxies, 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). 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 acts 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 to be cloned. This association can notably rely on the use of decentralized identifiers, known as "Decentralized IDs" (DIDs).

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

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

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

[0125] Specifically, the control plane includes controllers that are responsible for monitoring the cluster's state and performing actions to maintain, or achieve, the desired state. For example, there are controllers to manage deployments, services, replicas, and more. A controller manager is responsible for executing these controllers.

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

[0127] An API Server is intended to expose the Kubernetes API and serves as the main entry point for interacting with the cluster. A Load Balancer helps 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 real-time state of the Kubernetes cluster, 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 has several nodes (210, 220, 230, 310, 320, 330) which themselves contain pods. Each pod corresponds to an application deployment, whose related workload is represented by a cube. Some pods of interest, corresponding to specific application deployments, are also represented with sidecar proxies.

[0130] represents a final state of one of the clusters (200) following a pod cloning procedure, 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) into the second pod (222).

[0131] represents another final state of one of the clusters (200) following a node cloning procedure, 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) into the second node (230).

[0132] represents another final state of the clusters (200, 300) following 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 the 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 the replication of a node from a first cluster to a second cluster can obviously be applied in a similar manner 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 likely to support varied functional sets.

[0136] Regardless of the specific working environment of the resource to be assessed – 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

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) involved in 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 an operation of cloning resulting in the new deployment of the service. The module of claim 1, further configured to update the data topology in connection with the new deployment of the service. The module of claim 2, further configured to transmit an update message regarding the updated data topology and / or a configuration of the new deployment of the service to at least one third-party module. 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 service deployment following the cloning operation. 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. 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. Data processing system comprising a module according to one of claims 1 to 6. The system of claim 7, wherein the system is non-uniform memory access, NUMA. 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. 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. 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 an implementation of a cloning operation resulting in the new deployment of the service. A computer program comprising instructions which, when the program is implemented by a processor, result in implementing the method according to claim 11.

Images