EP4789094A1 - Module, procédé et programme utilisant une contrainte d'affinité de données pour un déploiement de service - Google Patents

Module, procédé et programme utilisant une contrainte d'affinité de données pour un déploiement de service

Info

Publication number
EP4789094A1
EP4789094A1 EP24773065.8A EP24773065A EP4789094A1 EP 4789094 A1 EP4789094 A1 EP 4789094A1 EP 24773065 A EP24773065 A EP 24773065A EP 4789094 A1 EP4789094 A1 EP 4789094A1
Authority
EP
European Patent Office
Prior art keywords
service
resource
module
resources
constraint
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24773065.8A
Other languages
German (de)
English (en)
Inventor
Gaël FROMENTOUX
Laurent VALEYRE
Frédéric FIEAU
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4789094A1 publication Critical patent/EP4789094A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5033—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering data affinity
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/502—Proximity

Definitions

  • 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.
  • 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.
  • the state of the art includes systems that use containerization technologies, such as Docker, and container orchestration technologies, such as Kubernetes.
  • the invention aims to improve the situation.
  • 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 an implementation of a cloning operation resulting in the new deployment of the service.
  • 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.
  • the module is further configured to update the data topology in relation to the new service deployment.
  • This refresh allows the data topology to evolve dynamically and ensures that the data remains consistent and optimized.
  • 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.
  • Transmitting update messages enables proactive communication with other modules or systems and facilitates seamless integration and collaboration between the affected modules or systems.
  • 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.
  • the data topology provides information about a neighborhood of each data item commonly associated with the service.
  • 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.
  • a data processing system comprising the discussed module.
  • the system is non-uniform memory access, NUMA.
  • 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.
  • system further includes a manager configured to manage the resource set and update the data topology in conjunction 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, 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.
  • 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 described.
  • FIG. 1 illustrates a resource management and cloning process according to an example implementation.
  • the present disclosure relates to a technique for facilitating service management in a cloud computing environment, specifically in telecommunications systems.
  • service is used in this document in a general way to encompass a service itself, one or more microservices, or even a complete application.
  • 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.
  • 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.
  • Cloning can be part of a migration process, 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 a process of instantiating a service in order to offer better performance to an increasing number of users.
  • Such a cloning system notably comprises a manager, an orchestrator and, optionally, a virtual service configured as a routing device.
  • 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.
  • 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 pieces of information on the use of individual resources from various data processing agglomerations. This or these pieces of 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).
  • the orchestrator can then identify one or more target resources in the same communication infrastructure, if applicable 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 respects the specified constraint(s).
  • 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.
  • 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 the "source resource" in the context of a cloning operation.
  • any suitable hardware and/or software means may be used for the practical implementation of the module.
  • 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.
  • 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.
  • 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.
  • NUMA non-uniform memory access systems
  • 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.
  • 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.
  • 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.
  • Cloud computing environments rely on one or more data processing systems as defined above.
  • 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.
  • Kubernetes is a system that facilitates the deployment, scaling, and management of containerized applications.
  • 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.
  • clusters which are sets of servers that work together and can be thought of as a single system.
  • a cluster 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 handle 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 containers.
  • auxiliary containers 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's 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.
  • ISTIO is an example of an open source service mesh, commonly used by networking and security operators to run distributed microservices-based applications, and provides a uniform way to connect, manage, and secure these microservices using sidecar proxies.
  • the proposed technique makes it possible to facilitate the implementation of cloning operations by a cloning system as described above.
  • the data processing system is configured such that one or more resources of the set of resources intervene for an initial deployment of the service, this or these resources are referred to as source resources.
  • the data processing system is configured such that one or more resources of the set of resources, different from the source resource(s), intervene for a new deployment of the service, this or these resources are referred to as destination resources.
  • patent application FR2306267 provides a procedure for identifying destination resources, for the implementation of cloning, according to a resource-aware policy.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • the affinity function takes into account at least one constraint. However, it has the ability to take into account a multitude of constraints, which can be related 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.
  • 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.
  • 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.
  • 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 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 the way in which data travels through the communication lines connecting the nodes.
  • 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.
  • 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.
  • constraints related to data topology and the architecture of the processing system 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.
  • cloning triggering 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.
  • 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.
  • 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.
  • This mode provides more dynamic and responsive resource management, as actions are based on the current state of resources and defined thresholds.
  • 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.
  • the telecom operator policy may relate to various aspects, including load sharing and/or resilience.
  • 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.
  • CG Cloud Gateway
  • 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.
  • the resources to be cloned are identified at block (108). These can be entire clusters, worker nodes, pods, applications, etc.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 of a given cluster determines whether or not this given cluster, as a whole, is capable of meeting this or these needs.
  • 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 correspond to the specific needs of the service to be deployed.
  • constraints such as computing performance, data isolation or the constraint of non-overlapping NUMA nodes are particularly relevant.
  • 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 the most appropriate for the task at hand. This results in better performance, better resource management, and increased satisfaction of specific customer or service needs.
  • the cluster containing one or more source resources may also contain one or more potential resources and it may be intended 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 or resources as destination resources without also implementing the affinity function at the global level and/or at the local level of other clusters.
  • 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.
  • the process of implementing the affinity function at the local level is a bit 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.
  • 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, let's 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.
  • 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.
  • Applying the affinity function to evaluate a potential resource may include a latency evaluation with a first separate score assigned based on whether the latency is low, medium, or high, a non-overlap evaluation with a second separate score assigned 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.
  • 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.
  • the data topology is updated.
  • the service routing information is updated.
  • the updates made at blocks (116) and (118) involve transmitting one or more update messages to various entities.
  • a memory manager can be configured to generate and transmit data topology update messages.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the tasks in 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.
  • proxy mode 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 greater adaptability and responsiveness to the internal conditions of the nodes.
  • 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.
  • 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
  • so-called "source” sidecar proxies play a dual role: they detect events at the source nodes and can request the orchestrator to trigger cloning. Source sidecar proxies can also trigger cloning themselves and then inform the orchestrator.
  • 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) of .
  • 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).
  • DIDs decentralized IDs
  • Each cluster is composed of a group of Masters and several nodes.
  • the Masters group forms a control plan responsible for the management and coordination of the different elements of the cluster.
  • control plane consists of 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 for managing deployments, services, replicas, and more. A controller manager is responsible for executing these controllers.
  • 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 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 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.
  • 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.
  • Each cluster also has several nodes (210, 220, 230, 310, 320, 330) which themselves contain pods.
  • Each pod corresponds to the deployment of an application, whose related workload is represented by a cube.
  • Some pods of interest, corresponding to specific application deployments, are also represented with sidecar proxies.
  • 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).
  • 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).
  • 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. Among the potential reasons may be the obtaining of 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.
  • 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.
  • a second node (330) has been successfully identified in the second cluster as a destination resource.
  • the cloning procedure has been implemented, replicating the first node (210) in the second node (330).
  • the procedure thus developed in connection with for the replication of a node from a first cluster to a second cluster can obviously be applied in an analogous 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.
  • 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.
  • the proposed technique is designed to adapt to these different contexts.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Stored Programmes (AREA)

Abstract

Il est proposé un module dans un environnement informatique en nuage, le module étant adapté pour opérer sur un système de traitement de données comprenant un ensemble de ressources (210, 212, 220, 230, 310, 320, 330), l'ensemble de ressources comprenant une ressource source (212, 220) intervenant pour un déploiement initial d'un service, le module étant configuré pour : évaluer (110), au sein de l'ensemble de ressources, au moins une ressource potentielle (210, 212, 220, 230, 310, 320, 330) pour un nouveau déploiement du service à l'aide d'une fonction d'affinité tenant compte d'au moins une contrainte relative à une topologie de données associées au service et/ou à une architecture du système de traitement de données, et lorsqu'un résultat d'évaluation d'une ressource potentielle est favorable, identifier (112) la ressource potentielle comme ressource de destination pour une mise en œuvre d'une opération de clonage aboutissant au nouveau déploiement du service.

Description

    Module, procédé et programme utilisant une contrainte d’affinité de données pour un déploiement de service
  • La présente divulgation se situe dans le domaine des technologies de l'information et des communications, et plus précisément dans le domaine des architectures de systèmes de télécommunications reposant sur des fonctions virtualisées hébergées dans un environnement informatique en nuage.
  • Elle concerne un module, un système à accès mémoire non uniforme comprenant un tel module, un procédé mis en œuvre par un tel module, et un programme d’ordinateur pour la mise en œuvre d’un tel procédé.
    •
  • L'état de l'art comprend des systèmes qui utilisent des technologies de conteneurisation, comme Docker, et d'orchestration de conteneurs, comme Kubernetes.
  • Ces systèmes sont conçus pour déployer des applications et des services sur des agglomérations de traitement de données, ou « clusters », en les répartissant sur plusieurs environnements de travail, ou « clouds ».
  • Cependant, ces systèmes existants ne fournissent pas de moyens pour répliquer des configurations de services ou d'applications déployées sur un cloud dans un autre.
  • En outre, ils ne fournissent pas non plus de mécanisme de reconfiguration de routage approprié pour optimiser l’emploi de ces services ou applications à la suite d’une telle réplication.
    • Résumé
  • L’invention vise à améliorer la situation.
  • Il est proposé, selon un aspect, un module dans un environnement informatique en nuage,
    le module étant adapté pour opérer sur un système de traitement de données comprenant un ensemble de ressources,
    l’ensemble de ressources comprenant une ressource source intervenant pour un déploiement initial d’un service,
    le module étant configuré pour :
    évaluer, au sein de l’ensemble de ressources, une ressource potentielle pour un nouveau déploiement du service à l’aide d’une fonction d’affinité tenant compte d’au moins une contrainte relative à une topologie de données associées au service et/ou à une architecture du système de traitement de données, et
    lorsqu’un résultat d’évaluation d’une ressource potentielle est favorable, identifier la ressource potentielle comme ressource de destination pour une mise en œuvre d’une opération de clonage aboutissant au nouveau déploiement du service.
  • Un tel module permet un nouveau déploiement optimisé et efficace du service en raison de l’évaluation préalable, à l’aide de la fonction d’affinité, d’une ou plusieurs ressources potentielles.
  • Dans un exemple, le module est configuré en outre pour actualiser la topologie des données en lien avec le nouveau déploiement du service.
  • Cette actualisation permet à la topologie des données d’évoluer dynamiquement et garantit que les données restent cohérentes et optimisées.
  • Dans un exemple, le module est configuré en outre pour transmettre un message de mise à jour concernant la topologie des données actualisée et/ou une configuration du nouveau déploiement vers au moins un module tiers.
  • Transmettre des messages de mise à jour permet une communication proactive avec d’autres modules ou systèmes et facilite l’intégration et la collaboration fluide entre les modules ou systèmes concernés.
  • Dans un exemple, le module est configuré en outre pour collaborer avec un orchestrateur pour mettre à jour un routage conformément à la topologie des données actualisée et au nouveau déploiement du service.
  • La mise à jour du routage garantit un routage optimisé pour le nouveau déploiement.
  • Dans un exemple, la topologie des données renseigne sur un voisinage de chaque donnée couramment associée au service.
  • Cela permet de mieux comprendre les relations et les dépendances impliquant, au moins, les données associées au service et éventuellement d’autres données et/ou d’autres services. Cette compréhension accrue peut être utilisée pour définir une variété de règles susceptibles d’être utilisées pour évaluer de ressources potentielles.
  • Dans un exemple, ladite au moins une contrainte comprend au moins une contrainte parmi une contrainte de latence, une contrainte de bande passante, une contrainte de charge, une contrainte de coût, une contrainte d’isolation, une contrainte de sécurité, une contrainte de potentiel d’accès, une contrainte de localisation géographique de la ressource potentielle et une contrainte de non-chevauchement de la ressource de destination et d’une ressource mémoire du système de traitement de données.
  • Ces différentes contraintes peuvent être considérées ensemble ou séparément et offrent la possibilité d’une évaluation détaillée, complète et précise d’une ou plusieurs ressources potentielles pour l’opération aboutissant au nouveau déploiement.
  • Il est également proposé, selon un aspect, un système de traitement de données comprenant le module évoqué.
  • Dans un exemple, le système est à accès mémoire non uniforme, NUMA.
  • La plupart des systèmes de traitement de données disponibles actuellement sont multiprocesseurs, ont une mémoire répartie entre les processeurs et présentent la caractéristique d’un accès mémoire non uniforme des processeurs aux données stockées en mémoire.
  • Dans un exemple, le système comprend en outre un orchestrateur configuré pour requérir l’identification de la ressource de destination par le module et diriger l'opération aboutissant au nouveau déploiement du service.
  • Dans un exemple, le système comprend en outre un gestionnaire configuré pour gérer l’ensemble de ressources et mettre à jour la topologie des données en liaison avec le module.
  • En intégrant non seulement le module, mais aussi l’orchestrateur et le gestionnaire, on obtient une architecture complète pour assurer de manière coordonnée la mise en œuvre du nouveau déploiement avec un routage optimisé dans le système de traitement de données, tel qu’un système NUMA.
  • Il est également proposé, selon un aspect, un procédé mis en œuvre par un module dans un environnement informatique en nuage, le module étant adapté pour opérer sur un système de traitement de données comprenant un ensemble de ressources, l’ensemble de ressources comprenant une ressource source intervenant pour un déploiement initial d’un service,
    le procédé comprenant :
    évaluer, au sein de l’ensemble de ressources, une ressource potentielle pour un nouveau déploiement du service à l’aide d’une fonction d’affinité tenant compte d’au moins une contrainte relative à une topologie de données associées au service et/ou à une architecture du système de traitement de données, et
    lorsqu’un résultat d’évaluation d’une ressource potentielle est favorable, identifier la ressource potentielle comme ressource de destination pour une mise en œuvre d’une opération de clonage aboutissant au nouveau déploiement du service.
  • Il est également proposé, selon un aspect, un programme d’ordinateur comprenant des instructions qui, lorsque le programme est mis en œuvre par un processeur, conduisent à mettre en œuvre le procédé évoqué.
    •
  • D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :
    • Fig. 1
  • illustre un processus de gestion de ressources et de clonage selon un exemple de réalisation.
    • Fig. 2
  • représente un état initial d’un système comprenant deux clusters avant la mise en œuvre d’un processus de clonage.
    • Fig. 3
  • représente un exemple d’état final du système de après la mise en œuvre d’un processus de clonage, reflétant des changements dans les clusters.
    • Fig. 4 Fig. 5
  • et représentent, chacun, un autre exemple d’état final du système de après la mise en œuvre d’un processus de clonage différent, reflétant des changements différents dans les clusters.
    •
  • Dans la description qui va suivre, des chiffres de référence identiques désignent des éléments identiques ou ayant des fonctions similaires.
  • La présente divulgation concerne une technique permettant de faciliter une gestion de services dans un environnement informatique en nuage, spécifiquement dans des systèmes de télécommunications.
  • Il est à noter en préambule que le terme « service » est utilisé dans le présent document de manière générale pour englober un service à proprement parler, un ou plusieurs microservices ou même une application complète. On entend par « application » un ensemble de fonctionnalités logicielles qui répondent à un besoin spécifique. Une application peut être composée d'un ou plusieurs services ou microservices qui travaillent ensemble pour fournir la fonctionnalité globale. Il convient de noter que la distinction entre un « service » et un « microservice » repose principalement sur l'échelle et le découpage fonctionnel de l'architecture logicielle d'une application. Un service est une unité fonctionnelle autonome qui peut couvrir un ensemble large de fonctionnalités et qui peut aussi bien former une partie d’une application plus large ou être utilisée par plusieurs applications. Un microservice est plus petit et est généralement responsable d'une fonctionnalité spécifique d’une application.
  • La technique proposée permet ainsi d’assister un système de clonage afin de répliquer des configurations supportant des services déployés dans un environnement informatique en nuage, spécifiquement dans des systèmes de télécommunications. Le clonage peut s’inscrire dans une démarche de migration, impliquant non seulement un nouveau déploiement d’un service, mais également une suppression du déploiement initial du service, de manière à par exemple assurer une continuité de service en anticipation d’une maintenance impliquant une mise hors ligne d’un serveur. Le clonage peut aussi s’inscrire dans une démarche d’instanciation d’un service afin d’offrir de meilleures performances à un nombre d’utilisateurs en augmentation.
  • Pour référence, un exemple de système de clonage approprié est détaillé dans la demande de brevet FR2306267. Un tel système de clonage comprend notamment un gestionnaire, un orchestrateur et, à titre optionnel, un service virtuel configuré comme un dispositif de routage.
  • Le gestionnaire joue un rôle clé dans le déclenchement du processus de clonage d’une configuration supportant un service. Il est capable de détecter un événement déclencheur résultant de l'application d'une stratégie de gestion du service. Suite à la détection de cet événement, le gestionnaire définit une ou plusieurs contraintes associées à l'événement et envoie des instructions de clonage à l'orchestrateur.
  • L’orchestrateur, dans l’environnement informatique en nuage, est conçu pour recevoir du gestionnaire une ou plusieurs instructions de clonage et ladite une ou plusieurs contraintes. L'orchestrateur est également capable de recueillir une ou plusieurs informations sur l'utilisation de ressources individuelles issues de diverses agglomérations de traitement de données. Cette ou ces informations sont obtenues avec une granularité suffisante pour permettre une analyse détaillée de l'utilisation de chaque ressource individuelle. L’interprétation de la ou des instructions par l’orchestrateur lui permet de désigner une ou plusieurs ressources définissant un déploiement initial d'un service au sein d'une infrastructure de communication initiale (ou environnement de travail initial). En tenant compte de la ou des instructions de clonage, de la contrainte reçue, et de la ou des informations recueillies, l'orchestrateur peut alors identifier une ou plusieurs ressources cibles dans la même infrastructure de communication, le cas échéant dans le même cluster, ou dans au moins une nouvelle infrastructure de communication. Cela permet un clonage de la ou des ressources désignées, facilitant ainsi un nouveau déploiement du service qui respecte la ou les contraintes spécifiées.
  • Le service virtuel configuré comme un dispositif de routage peut être configuré pour rediriger, à l'issue d'une opération de clonage, tout ou partie d’un trafic réseau du déploiement initial du service concerné vers le nouveau déploiement, de manière transparente pour l'orchestrateur et le gestionnaire. Cela permet une transition fluide et efficace entre le déploiement initial et le nouveau déploiement, contribuant ainsi à la continuité du service.
  • Outre la description ci-dessus du système de clonage, toutes les précisions figurant dans la demande de brevet FR2306267 et définissant de manière plus précise le système de clonage ou son principe de fonctionnement pour mettre en œuvre des opérations de clonage peuvent s’appliquer de manière identique au système de clonage et aux opérations de clonage décrits dans le présent document, sauf précision contraire.
  • Un aspect de la technique proposée dans le présent document est un module adapté pour opérer sur un système de traitement de données comprenant un ensemble de ressources, dont une ressource définissant un déploiement initial d’un service. La ressource définissant le déploiement initial du service considéré est appelée « ressource source » dans le contexte d’une opération de clonage.
  • Tous moyens matériels et/ou logiciels adaptés peuvent être utilisés pour la mise en œuvre pratique du module. De manière générale, bien que des aspects de la technique proposée puissent être décrits dans le présent document comme étant un processus, un dispositif, un système, une procédure ou une méthode, il est à noter que la technique proposée peut également couvrir une mémoire informatique susceptible d’être raccordée à un processeur éventuellement raccordé à une interface de communication, la mémoire stockant des instructions qui, lorsqu'elles sont exécutées par un tel processeur, permettent de réaliser les processus, dispositifs, systèmes, procédures ou méthodes décrits dans ce document.
  • Il est entendu que, dans le contexte de l’assistance à une opération de clonage, le module peut être intégré au système de clonage décrit précédemment et/ou peut être configuré pour communiquer avec le système de clonage de manière à faciliter l’identification par l’orchestrateur d’une ou plusieurs ressources cibles.
  • Quelques termes spécifiques aux systèmes de traitement de données et aux environnements informatiques en nuage sont à présent clarifiés pour une meilleure compréhension de la technique proposée.
  • L’expression « système de traitement de données » se réfère à un support physique et logiciel qui permet la communication et le partage de ressources et de services dans l’environnement informatique en nuage. Ce système peut désigner une infrastructure de communication ou une ou plusieurs de ses sous-parties, notamment des systèmes de traitement et de stockage de données, des serveurs et des réseaux, des centres de données, des systèmes cloud, des équipements de télécommunication, etc. Il peut aussi bien concerner l'infrastructure de communication au sein d'une organisation spécifique, comme un réseau interne d'ordinateurs et de serveurs, ou une infrastructure plus large, comme un réseau de télécommunications ou le cloud. La technique proposée est applicable à tout type de système de traitement de données.
  • De nos jours, la plupart des systèmes de traitement de données ont une architecture multiprocesseur. L'accès à la mémoire influence beaucoup les performances et la façon de programmer de telles architectures. On distingue deux classes principales d’architectures multiprocesseur selon la façon dont les processeurs accèdent à la mémoire, à savoir les architectures à accès symétrique et celles à accès non uniforme. Les systèmes à accès mémoire non uniforme, également appelés dans l’art systèmes NUMA, présentent des avantages en matière de rapidité des flux de données entre processeurs et zones mémoire. Un système NUMA est un système à architecture multiprocesseur comprenant plusieurs zones mémoires séparées et placées en différents endroits et sur différents bus raccordés à un même réseau d’interconnexion. Un corollaire de cette distribution de la mémoire est une facilitation des accès concurrents par les différents processeurs. Une particularité d’un système NUMA est que, vis-à-vis de chaque processeur, les temps d’accès diffèrent suivant la zone mémoire accédée.
  • Dans le contexte d’un système NUMA, un « nœud » ou « nœud NUMA » désigne un ensemble formé par une zone mémoire, un processeur et une interface de communication, le tout situé sur un même bus. Une « distance » représente un nombre de sauts d’un nœud à un autre pour mettre en œuvre une tâche particulière dans le cadre de la mise en œuvre d’un service.
  • Un système de traitement de données comporte un ensemble de ressources susceptibles d’être réservées aux fins d’un fonctionnement d’un ou plusieurs services. Cet ensemble de ressources peut inclure des ressources de types variés, notamment des temps de calcul au niveau d’un ou plusieurs processeurs, des emplacements d’une ou plusieurs mémoires, ou encore des créneaux d’utilisation, exprimés par exemple en temps et/ou en fréquence, d’un ou plusieurs canaux de communication.
  • Les environnements informatiques en nuage s’appuient sur un ou plusieurs systèmes de traitement de données tels que définis ci-avant.
  • Dans ces environnements, l'unité d'hébergement de base est souvent appelée un « conteneur ». Ces conteneurs sont des unités logicielles légères qui encapsulent le code et toutes ses dépendances, permettant ainsi à une application de s’exécuter de manière fiable d'un environnement informatique à un autre.
  • Pour la gestion de ces conteneurs, une solution appelée Kubernetes, K8S, est fréquemment employée. Kubernetes est un système qui facilite le déploiement, la mise à l'échelle et la gestion des applications conteneurisées.
  • Dans l'architecture de Kubernetes, les conteneurs sont regroupés en « pods », qui constituent l’unité de base représentant un déploiement d'une application. Plusieurs pods peuvent être regroupés en un « Node » ou « nœud », qui symbolise un serveur. La définition du « Node » ou « nœud » dans l’architecture de Kubernetes correspond à celle du « nœud » dans le système NUMA. Ces nœuds sont ensuite regroupés en « clusters », soit des ensembles de serveurs qui travaillent ensemble et peuvent être perçus comme un système unique.
  • Dans le contexte de Kubernetes, un cluster est constitué d'un groupe de « Masters » et de Nodes. Les Masters sont les composants du cluster Kubernetes qui fournissent l'interface de contrôle pour le cluster, et qui gèrent l'ordonnancement des pods, la détection et la gestion des échecs, ainsi que le déploiement de nouvelles versions des applications. Les Nodes, quant à eux, sont les serveurs qui exécutent les applications et qui fournissent l'environnement d'exécution pour les conteneurs.
  • Pour gérer les communications réseau entre les conteneurs d'une application déployée sur un cluster Kubernetes, des conteneurs auxiliaires, dits « proxy sidecar » sont attachés à chaque conteneur principal de l’application. Les proxys sidecar sont responsables de l'interception et de la gestion des communications réseau. Chaque proxy sidecar agit en tant qu'intermédiaire entre le conteneur principal auquel il est attaché et le reste du réseau. Pour renforcer la sécurité, les proxys sidecar peuvent inclure des fonctions telles que la validation des requêtes et des réponses, la gestion des autorisations et des identités, ainsi que la surveillance et l'alerte en cas d'anomalies.
  • ISTIO est un exemple de maillage de services open source, couramment utilisé par des opérateurs de mise en réseau et de sécurité pour l’exécution d’applications distribuées basées sur des microservices, et qui fournit une manière uniforme de connecter, gérer et sécuriser ces microservices à l’aide de proxys sidecar.
  • La technique proposée permet de faciliter la mise en œuvre d’opérations de clonage par un système de clonage tel que décrit précédemment. A cet effet, on peut par exemple définir un état initial du système de traitement de données à un instant initial avant une mise en œuvre d’une opération de clonage relative à un service et un état final du système de traitement de données à un instant final après la mise en œuvre de l’opération de clonage. A l’instant initial, le système de traitement de données est configuré de telle sorte qu’une ou plusieurs ressources de l’ensemble de ressources interviennent pour un déploiement initial du service, cette ou ces ressources sont qualifiées de ressources source. A l’instant final, le système de traitement de données est configuré de telle sorte qu’une ou plusieurs ressources de l’ensemble de ressources, différentes de la ou des ressources source, interviennent pour un nouveau déploiement du service, cette ou ces ressources sont qualifiées de ressources de destination.
  • A titre d’illustration, la demande de brevet FR2306267 prévoit une procédure d’identification de ressources de destination, pour la mise en œuvre d’un clonage, selon une politique consciente des ressources. Mais cette politique ne prend pas en compte l’affinité entre processus et données, laquelle est désormais au cœur de la recherche de performance, en particulier dans la gestion de systèmes NUMA. Un exemple particulier de domaine d’application où l’affinité entre processus et données est cruciale est le placement de micro-services dans un système de télécommunications 5G.
  • La technique proposée dans le présent document offre une procédure robuste pour la détermination, au sein de l’ensemble de ressources, d’une ou plusieurs ressources de destination appropriées parmi un ensemble plus grand de ressources potentielles. Cette procédure convient tout particulièrement dans les domaines où l’affinité entre processus et données est un facteur de performance important.
  • Dans ce but, le module est configuré pour évaluer, au sein de l’ensemble de ressources, au moins une ressource potentielle pour un déploiement d’un service à l’aide d’une fonction d’affinité.
  • Le résultat de l’évaluation peut être favorable ou défavorable et peut concerner une seule ressource potentielle ou un groupe de ressources potentielles évaluées simultanément. Le module peut également être configuré pour évaluer plusieurs ressources ou groupes de ressources potentielles successivement, auquel cas un résultat d’évaluation distinct est obtenu pour chaque évaluation.
  • Le module est également configuré pour identifier une ou plusieurs ressources potentielles ayant un résultat d’évaluation favorable comme ressources attribuables au déploiement du service. A l’inverse, le module est également configuré pour ne pas identifier, le cas échéant, une ou plusieurs ressources potentielles ayant un résultat d’évaluation défavorable comme ressources attribuables au déploiement du service. Une ressource identifiée comme attribuable au service est une ressource de destination pour la mise en œuvre d’une opération de clonage aboutissant au nouveau déploiement du service, tandis qu’une ressource identifiée comme non attribuable au service n’est pas une telle ressource de destination.
  • La fonction d’affinité se trouve au cœur de la technique proposée. Elle détermine la manière dont les ressources sont évaluées en fonction de divers critères ou contraintes dans le cadre d’un processus de clonage.
  • La fonction d’affinité tient compte d’au moins une contrainte. Cependant, elle a la capacité de prendre en considération une multitude de contraintes, qui peuvent être relatives soit à la topologie des données associées au service, soit à l’architecture du système de traitement, soit à une combinaison des deux. En prenant potentiellement en compte une variété de contraintes, l’application de la fonction d’affinité contribue à une gestion optimale des ressources, permettant d’offrir par exemple une performance et/ou une sécurité accrues pour l’utilisateur final.
  • Pour définir la nature des contraintes, pouvant également être appelées critères, il convient de définir également ce que l’on entend par « topologie des données » et par « architecture du système de traitement ».
  • Dans le contexte de la technique proposée, la topologie des données ne fait pas référence à la topologie du réseau informatique sous-jacent. Elle concerne plutôt des informations sur le voisinage des données associées à un même service. Ces données peuvent avoir des interactions entre elles ou avec différentes entités du réseau, notamment les mémoires et les processeurs. Les interactions peuvent inclure des appels de fonction, des requêtes de données, ou d’autres formes de communication.
  • Les contraintes liées à la topologie des données peuvent comprendre des contraintes d’isolation, c’est-à-dire assurant que certaines données restent isolées des autres, et de sécurité, c’est-à-dire veillant à ce que l’accès aux données soit non autorisé ou autorisé en fonction de certains critères ou bien encore que l’accès aux données soit interdit.
  • L’architecture du système de traitement peut être physique ou logique. Elle définit les liaisons entre les entités du réseau et leur hiérarchie éventuelle. L’architecture ou topologie physique du système de traitement est une représentation spatiale du système de traitement. Dans le cas d’un système NUMA, il s’agit de la façon dont les nœuds qui le composent sont interconnectés. On peut citer, parmi les topologies classiques, des topologies en bus, en anneau, en étoile ou maillées. Toujours dans le cas d’un système NUMA, l’architecture ou topologie logique définit la façon dont les données transitent dans les lignes de communication raccordant les nœuds.
  • Les contraintes liées à l’architecture englobent des contraintes telles que le coût, c’est-à-dire l’évaluation économique de l’utilisation d’une ressource par rapport à une autre, le potentiel d’accès, c’est-à-dire la facilité avec laquelle une ressource peut être accédée, la localisation géographique, c’est-à-dire l’emplacement physique d’une ressource et le non-chevauchement.
  • La contrainte de non-chevauchement, lorsqu’elle est appliquée à une architecture NUMA, assure que les ressources ne se chevauchent pas ou ne sont pas superposées dans la même zone mémoire. La contrainte de non-chevauchement de nœuds NUMA peut être spécifiquement booléenne.
  • On peut également citer des contraintes liées à la topologie des données et à l’architecture du système de traitement. Cela inclut des contraintes de latence, c’est-à-dire le temps nécessaire pour accéder à une donnée, de bande passante, c’est-à-dire la quantité de données qui peuvent être transmises en un temps donné, de charge, c’est-à-dire la quantité de travail ou de demandes qu’une ressource peut gérer), de performance de calcul, c’est-à-dire la vitesse à laquelle une opération peut être exécutée), ou encore de performance énergétique, c’est-à-dire la quantité d’énergie consommée pour réaliser une opération).
  • À présent, nous allons décrire un mode particulier de mise en œuvre de la technique proposée, en lien avec un procédé de clonage, dans le contexte d’un système NUMA et d’une plateforme Kubernetes.
  • Il va de soi que l’homme du métier est capable de transposer les réalisations exposées dans le présent document dans le contexte de toute autre opération impliquant l’allocation d’une ressource d’un système quelconque de traitement de données et utilisant une plateforme quelconque de gestion de conteneurs.
  • Deux modes de déclenchement du clonage sont envisagés : le mode « orchestrateur » et le mode « proxy ».
  • La différence principale entre le mode « orchestrateur » et le mode « proxy » réside dans la manière dont le déclenchement du clonage est réalisé et la dynamique de réaction face à l’état des ressources.
  • Dans le mode « orchestrateur », le déclenchement du clonage est principalement contrôlé par un orchestrateur central qui se base sur les préférences de l’utilisateur et les règles de politique définies par l’opérateur de télécommunications. Ces préférences et règles sont définies à l’avance, et l’orchestrateur utilise ces informations pour gérer les ressources et déclencher le processus de clonage. Les actions sont donc largement prédéterminées et dépendent de la planification et de la stratégie définies par les règles de l’opérateur.
  • Ce mode offre une gestion des ressources particulièrement prévisible, car les actions sont basées sur des règles et des préférences établies. Il convient mieux aux environnements stables où les demandes de ressources sont prévisibles et où la politique de l’opérateur est bien définie.
  • En mode « proxy », le processus de clonage est déclenché en réponse à des événements internes aux nœuds, qui peuvent être liés à une atteinte ou à un dépassement d’un seuil prédéterminé en matière d’utilisation des ressources. Ainsi, le clonage est déclenché de manière plus dynamique, en réponse à l’état réel des ressources. Les proxys sidecar jouent un rôle actif dans la détection des événements et la transmission des informations à l’orchestrateur.
  • Ce mode offre une gestion des ressources plus dynamique et réactive, car les actions sont basées sur l’état actuel des ressources et les seuils définis.
  • Il est plus adapté aux environnements dynamiques et incertains, où l’utilisation des ressources peut varier rapidement ou de manière imprévisible.
  • Il est important de noter que le choix entre le mode « orchestrateur » et le mode « proxy » dépendra de l’environnement spécifique, des exigences de l’opérateur et des caractéristiques de la charge de travail. Dans certains cas, une combinaison des deux modes peut être utilisée pour profiter des avantages de chacun.
  • illustre un processus de gestion de ressources et de clonage selon le mode « orchestrateur ».
  • Des préférences d’un utilisateur et des règles de politique de l’opérateur télécom sont établies au bloc (102) par des systèmes de soutien aux entreprises ou aux opérations, dits « Business Support Systems / Operations Support Systems », BSS/OSS, en anglais. De tels systèmes informatiques sont utilisés par les opérateurs télécom pour gérer leurs réseaux. La politique de l’opérateur télécom peut être relative à différents aspects, dont le partage de charge et/ou la résilience.
  • Dans le mode « orchestrateur », le gestionnaire peut appliquer les préférences et/ou règles établies au bloc (102) en envoyant des demandes de service, c’est-à-dire des instructions, à l’orchestrateur qui les exécute et déclenche ainsi un processus de clonage.
  • Au bloc (104), les ressources disponibles sont vérifiées. Cette action est effectuée par une plateforme, dite « Cloud Gateway », CG, en anglais, qui facilite l’accès sécurisé aux services cloud et par l’orchestrateur, en tant que système qui gère l’exécution et l’interaction entre les tâches et les services.
  • Au bloc (106), l’orchestrateur détermine si les ressources disponibles permettent ou non d’appliquer les demandes de service reçues. Dans la négative, en raison d’un manque de ressources disponibles tel que révélé au bloc (104), aucun clonage n’est mis en œuvre.
  • Lorsque les ressources disponibles sont suffisantes pour permettre l’application des demandes de service, les ressources à cloner sont identifiées au bloc (108). Il peut s’agir de clusters entiers, de nœuds de travail, de pods, d’applications, etc.
  • La fonction d’affinité est mise en œuvre (110) afin d’évaluer des ressources potentielles, c’est-à-dire tout ou partie des ressources disponibles, et d’identifier des ressources de destination au sein de ces ressources potentielles.
  • En fonction des résultats des évaluations des ressources potentielles, des ressources de destination sont identifiées au bloc (112). Les ressources de destination sont destinées à héberger les clones des ressources identifiées au bloc (108). Ces ressources sont susceptibles d’inclure des nœuds effectuant diverses tâches de traitement, dits « Processing Node », PN, des nœuds effectuant plus particulièrement des tâches de traitement liées au fonctionnement du réseau, dits « Network Processing Node », NPN, en anglais, ainsi que des terminaux ou équipements utilisateur, dits « User Equipment », UE, en anglais.
  • La mise en œuvre de la fonction d’affinité peut par exemple se faire à deux niveaux distincts, c’est-à-dire d’une part à un niveau global, c’est-à-dire déroulée à l’échelle du système de traitement de données ou réseau dans son ensemble, et d’autre part à un niveau local, c’est-à-dire au sein d’un cluster spécifique.
  • La mise en œuvre de la fonction d’affinité à un niveau global implique la prise en compte de plusieurs clusters, qui pourraient chacun contenir des ressources potentielles. Les clusters sont évalués en fonction d’une ou plusieurs contraintes spécifiques se rapportant par exemple au service concerné par l’opération de clonage.
  • Il peut s’agir par exemple de latence ou de bande passante, qui peuvent impacter directement l’expérience utilisateur. Par exemple, un client souhaitant déployer une application en temps réel via le système de traitement de données pourrait exiger que la latence ne dépasse pas un certain seuil. À ce niveau, la fonction d’affinité permet d’évaluer chaque cluster par rapport à cette ou ces contraintes. Le résultat d’évaluation d’un cluster donné détermine si ce cluster donné, dans son ensemble, est apte ou non à répondre à ce ou ces besoins.
  • Une fois qu’un cluster particulier a été identifié comme approprié au niveau global, la fonction d’affinité peut entrer en jeu une seconde fois à une échelle plus fine, c’est-à-dire au sein même du cluster. Cette évaluation granulaire permet de sélectionner, parmi des nœuds ou ressources du cluster, ceux qui correspondent le mieux aux besoins spécifiques du service à déployer. Ici, des contraintes comme la performance de calcul, l’isolation des données ou encore la contrainte de non-chevauchement de nœuds NUMA sont particulièrement pertinentes.
  • Pour illustrer, imaginons un service nécessitant des calculs intensifs mais isolés. Dans un cluster, certains nœuds peuvent partager leur mémoire (nœuds NUMA superposés). La contrainte de non-chevauchement garantit que les nœuds sélectionnés n’ont pas de superposition, assurant ainsi une utilisation efficace des ressources et prévenant les potentiels goulets d’étranglement ou interférences. L’avantage technique majeur ici est d’optimiser les performances et de garantir une exécution fluide du service en question.
  • En somme, cette double application de la fonction d’affinité, à la fois au niveau global et local, garantit non seulement que le cluster choisi est adapté dans son ensemble, mais également que les ressources spécifiques au sein de ce cluster sont les plus adéquates pour la tâche à accomplir. Il en résulte une meilleure performance, une meilleure gestion des ressources et une satisfaction accrue des besoins spécifiques du client ou du service.
  • Alternativement, il est possible, dans certains cas, de mettre en œuvre la fonction d’affinité à un seul niveau. Par exemple, le cluster contenant une ou plusieurs ressources source peut également contenir une ou plusieurs ressources potentielles et il peut être prévu d’évaluer en premier lieu cette ou ces ressources potentielles au niveau local et, en cas de résultat d’évaluation positif, d’identifier la ou les ressources potentielles correspondantes comme ressources de destination sans mettre également en œuvre la fonction d’affinité au niveau global et/ou au niveau local d’autres clusters.
  • Un intérêt de cette démarche est lié au fonctionnement de la plateforme Kubernetes, où chaque cluster dispose de son propre plan de contrôle, c’est-à-dire de son propre contrôleur local. Le processus de mise en œuvre de la fonction d’affinité est relativement simple dans le cas où une ou des ressources source et une ou des ressources potentielles à évaluer appartiennent au même cluster et sont déjà toutes connues du contrôleur local. Un autre intérêt de cette démarche est que, lorsque les ressources initiales et celles utilisées pour le nouveau déploiement se trouvent dans le même cluster, la synchronisation et la transmission des données entre elles sont généralement plus rapides et plus efficaces. Cela facilite et accélère le processus de clonage, car les données n’ont pas besoin de traverser les limites du cluster ou de faire face à d’éventuelles latences réseau extérieures.
  • Lorsqu’une ressource potentielle et une ressource source se trouvent dans des clusters distincts, le processus de mise en œuvre de la fonction d’affinité au niveau local est un peu plus complexe. Le contrôleur local du cluster contenant la ressource source, ou une entité centrale telle que l’orchestrateur ou le gestionnaire, notifie le contrôleur local du cluster contenant la ressource potentielle à évaluer en fournissant une liste de contraintes à prendre en compte. Le contrôleur local du cluster contenant la ressource potentielle à évaluer utilise la fonction d’affinité pour évaluer la ressource potentielle selon les contraintes fournies. Une confirmation d’évaluation peut ensuite être transmise au contrôleur local du cluster contenant la ressource source et/ou à une entité centrale telle que l’orchestrateur ou le gestionnaire. La confirmation d’évaluation peut comprendre le résultat d’évaluation de la ressource potentielle.
  • Un exemple concret d’application d’une fonction d’affinité pour évaluer une ressource potentielle à un niveau local est à présent décrit en utilisant deux exemples de contraintes : la contrainte de latence et la contrainte de non-chevauchement, en supposant qu’un conteneur ait besoin d’une latence faible pour fonctionner efficacement et qu’il ne doive pas être superposé avec d’autres conteneurs dans le même nœud NUMA.
  • La latence est le temps qu’il faut pour que les données soient transférées d’un point à un autre. Dans le contexte d’un système de traitement de données NUMA, cela peut par exemple se référer à la latence entre différents nœuds. Pour cet exemple, supposons que la latence admet trois groupes de valeurs possibles, mesurées en microsecondes (µs) : faible lorsqu’inférieure à 10µs, moyenne lorsque comprise entre 10µs et 50µs, et élevée lorsque supérieure à 50µs.
  • La contrainte de non-chevauchement assure que les ressources ne se chevauchent pas ou ne sont pas superposées dans la même zone mémoire. Deux valeurs booléennes possibles peuvent être choisies par convention, par exemple « True » (Vrai) lorsqu’aucun chevauchement n’est autorisé et « False » (Faux) lorsque le chevauchement est autorisé, ou l’inverse.
  • L’application de la fonction d’affinité pour évaluer une ressource potentielle peut comprendre une évaluation de la latence avec attribution d’un premier score distinct selon que la latence est soit faible soit moyenne ou élevée, une évaluation du non-chevauchement avec attribution d’un deuxième score distinct selon que le chevauchement est possible ou non, et une évaluation globale de la ressource potentielle combinant le premier et le deuxième score pour obtenir un score total en tant que résultat d’évaluation.
  • A titre d’exemples, quatre résultats d’évaluation possibles sont détaillés dans un scénario où l’on souhaite déployer un conteneur dans l’une parmi quatre ressources potentielles correspondantes nommées A, B, C et D.
  • Ressource A : Latence faible (<10µs) + Pas de chevauchement = Score total élevé.
  • Ressource B : Latence moyenne (25µs) + Pas de chevauchement = Score total moyen.
  • Ressource C : Latence faible (<10µs) + Possibilité de chevauchement = Score total moyen.
  • Ressource D : Latence élevée (60µs) + Possibilité de chevauchement = Score total faible.
  • Dans cet exemple, la ressource A serait ainsi la plus appropriée pour déployer le conteneur en question en raison de sa latence faible et de l’absence de chevauchement. Ceci est un exemple simplifié pour illustrer le concept. Dans un environnement réel, de nombreux autres facteurs et contraintes pourraient être pris en compte pour déterminer la meilleure ressource pour déployer un conteneur ou un ensemble de conteneurs.
  • Au bloc (114), le clonage est effectué.
  • Au bloc (116), la topologie des données est mise à jour. Au bloc (118), les informations de routage du service sont mises à jour. Les mises à jour effectuées aux blocs (116) et (118) impliquent la transmission d’un ou plusieurs messages de mise à jour à destination de diverses entités.
  • Notamment, un gestionnaire de mémoire peut être configuré pour générer et transmettre les messages de mise à jour de la topologie des données.
  • Le gestionnaire de mémoire, ou « Memory Manager » en anglais, est une fonctionnalité de Kubernetes qui vise à améliorer la performance des services qui nécessitent des ressources mémoire spécifiques pour leur fonctionnement optimal, en particulier dans les environnements où les ressources mémoire sont fragmentées ou limitées. Il contribue à une gestion efficace de la mémoire sur les nœuds dans des scénarios où les performances sont critiques, en particulier dans des scénarios utilisant un système de traitement de données NUMA.
  • Il peut être prévu par exemple que le gestionnaire de mémoire transmette un message de mise à jour contenant des informations de nouvelles configurations matérielles dues au clonage à un système de gestion des composants matériels du système de traitement de données, tels que des nœuds assurant le traitement des données ou des disques assurant le stockage des données. Ce système peut alors mettre à jour la configuration matérielle du système de traitement de données.
  • Il peut être prévu par exemple que le gestionnaire de mémoire transmette un message de mise à jour contenant les nouvelles instances de pods créés pendant le clonage à un orchestrateur de fonctions réseau virtualisées. L’orchestrateur de fonctions réseau virtualisées peut alors mettre à jour sa liste d’instances actives en conséquence, pour assurer une gestion plus précise du cycle de vie des fonctions réseau virtualisées.
  • Il peut être prévu par exemple que le gestionnaire de mémoire transmette un message de mise à jour contenant de nouveaux liens suite au clonage ou des modifications suite au clonage de liens préexistants au clonage à un contrôleur de réseau programmable et/ou à une infrastructure de fonctions réseau virtualisées. Ces entités peuvent alors mettre à jour leurs topologies pour participer à une meilleure gestion du trafic.
  • Il peut être prévu par exemple que le gestionnaire de mémoire transmette un message de mise à jour relatif à de nouveaux états du système de traitement de données suite au clonage au systèmes de soutien aux entreprises et/ou au système de soutien aux opérations (BSS/OSS), pour permettre de synchroniser les informations opérationnelles et d’entreprise avec les états actuels du système de traitement de données et ainsi contribuer à une meilleure visibilité et à une gestion améliorée des ressources et des clients. Alternativement, ce message de mise à jour peut aussi être transmis par le système de gestion des composants matériels du système de traitement de données après que ce dernier ait lui-même reçu un message de mise à jour du gestionnaire de mémoire et mis à jour la configuration matérielle du système de traitement de données en conséquence.
  • Les tâches des blocs (114) à (118) peuvent être mises en œuvre par Kubernetes ou par ISTIO. Indépendamment du mode retenu de déclenchement, le clonage permet de simplifier et de sécuriser l’accès aux fonctions ou microservices formant une application donnée ou un service donné, en reproduisant la logique d’accès aux données et la sécurité associée.
  • Dans le mode « proxy », les proxys sidecar jouent un rôle crucial dans le déclenchement d’une opération de clonage. Contrairement au mode « orchestrateur », qui déclenche le clonage à partir d’instructions prédéterminées, le mode « proxy » répond dynamiquement aux conditions internes de chaque nœud. Ainsi, le clonage déclenché à travers le mode « proxy » permet une meilleure adaptabilité et réactivité face aux conditions internes des nœuds.
  • Pour clarifier, des seuils d’utilisation des ressources sont établis pour chaque nœud, tenant compte de divers facteurs tels que le nombre de requêtes par seconde, la taille des requêtes, la consommation d’énergie et l’utilisation de la mémoire vive. Lorsqu’un de ces seuils est atteint ou dépassé, un événement est déclenché au niveau du conteneur concerné.
  • L’information de cet événement peut être ensuite transmise à l’orchestrateur par le proxy sidecar du conteneur. Cela peut également être relayé au gestionnaire. L’orchestrateur et/ou le gestionnaire utilisent ensuite ces événements pour déterminer les actions appropriées à réaliser, y compris potentiellement un processus de clonage similaire à celui du mode « orchestrateur » tel que reflété aux blocs (112) à (118) de . Ici, des proxys sidecar dits « source » jouent un rôle double : ils détectent les événements au niveau des nœuds sources et peuvent demander à l’orchestrateur de déclencher le clonage. Les proxys sidecar source peuvent aussi déclencher le clonage eux-mêmes et ensuite en informer l’orchestrateur.
  • Sur réception de l’information issue des proxys sidecar source, l’orchestrateur peut alors désigner des ressources de destination soit de lui-même, soit à l’issue d’un dialogue avec un autre orchestrateur ou avec d’autres proxys sidecar dits « de destination », qui sont associés aux ressources qui vont accueillir les clones des services et/ou des configurations. Le clonage est ensuite effectué et les informations de routage du service sont mises à jour de la même manière qu’indiqué aux blocs (14) à (18) de . Pour faciliter la communication pendant ce processus, de nouveaux canaux de communication sont mis en place, par exemple par l’orchestrateur, entre les proxys sidecar source et de destination, ainsi qu’entre les proxys sidecar source et les masters associés aux ressources de destination. L’orchestrateur sert de pivot dans ce réseau complexe, associant chaque proxy sidecar source et de destination à un groupe de ressources identifiées hébergeant les services ou applications concernés par le clonage. Cette association peut notamment reposer sur l’utilisation d’identifiants décentralisés, dits « Decentralized ID », DID, en anglais.
  • illustre de manière schématique deux clusters Kubernetes (200, 300).
  • Chaque cluster est composé d’un groupe de Masters et de plusieurs nœuds.
  • Le groupe de Masters forme un plan de contrôle responsable de la gestion et de la coordination des différents éléments du cluster.
  • En particulier, le plan de contrôle comporte des modules de commande (« Controllers » en anglais) chargés de surveiller l’état du cluster et d’effectuer des actions pour maintenir, ou parvenir à, l’état souhaité. Il existe par exemple des modules de commande pour gérer des déploiements, des services, des réplicas, entre autres. Un gestionnaire de modules de commande (« Controller Manager » en anglais) est responsable de l’exécution de ces modules de commande.
  • D’autres composants du plan de contrôle jouent des rôles spécifiques.
  • Un serveur API (« API Server » en anglais) est prévu pour exposer l’API de Kubernetes et sert de principal point d’entrée pour interagir avec le cluster. Un équilibreur de charge (« Load Balancer » en anglais) permet de répartir la charge du trafic entrant vers différents services en distribuant le trafic entre les nœuds du cluster ou entre des pods fonctionnant sur différents nœuds. Un ordonnanceur (« Scheduler » en anglais) est chargé d’attribuer les pods aux nœuds du cluster en fonction de besoins en ressources, de contraintes et de politiques définies. Une base de données appelée ETCD stocke en temps réel l’état du cluster Kubernetes, y compris des informations sur les nœuds, les pods, les services, les configurations, etc.... Elle rend ces informations accessibles en lecture et en écriture à tous les composants du cluster en temps réel.
  • Il est considéré qu’à un instant donné, l’ensemble du plan de contrôle d’un cluster donné (200, 300), ou au moins l’un de ses composants, tels que le gestionnaire de modules de commande, un module de commande spécifique, le serveur API, l’équilibreur de charge, ou l’ordonnanceur, joue le rôle d’un orchestrateur (202, 302) mettant en œuvre une procédure de clonage.
  • Chaque cluster comporte également plusieurs nœuds (210, 220, 230, 310, 320, 330) qui contiennent eux-mêmes des pods. Chaque pod correspond au déploiement d’une application, dont la charge de travail afférente est représentée par un cube. Certains pods d’intérêt, correspondant à des déploiements d’applications spécifiques, sont également représentés avec des proxys sidecar.
  • représente un état final de l’un des clusters (200) de à l’issue d’une procédure de clonage d’un pod, dans un exemple de réalisation. L’orchestrateur (202) a d’abord identifié un premier pod (212) situé dans un premier nœud (210) du cluster (200) en tant que ressource d’origine. L’orchestrateur a ensuite désigné un second pod (222) situé dans un second nœud (220) de ce même cluster (200) en tant que ressource de destination. Après cela, la procédure de clonage a été mise en œuvre, répliquant le premier pod (212) dans le second pod (222).
  • représente un autre état final de l’un des clusters (200) de à l’issue d’une procédure de clonage d’un nœud, dans un autre exemple de réalisation. L’orchestrateur (202) a d’abord identifié un premier nœud (220) du cluster (200) en tant que ressource d’origine. L’orchestrateur a ensuite désigné un second nœud (230) de ce même cluster (200) en tant que ressource de destination. Après cela, la procédure de clonage a été mise en œuvre, répliquant les pods du premier nœud (220) dans le second nœud (230).
  • représente un autre état final des clusters (200, 300) de à l’issue d’une procédure de clonage d’un noeud, dans un autre exemple de réalisation. L’orchestrateur (202) situé dans un premier cluster (200) a d’abord identifié, dans le premier cluster (200), un nœud à cloner (210), en tant que ressource source. On peut supposer ici que l’orchestrateur (202) n’était pas en mesure d’identifier un nœud de destination dans le premier cluster. Parmi les raisons potentielles peuvent être l’obtention d’un ou plusieurs résultats d’évaluation défavorables suite à la mise en œuvre d’une fonction d’affinité à un niveau global pour évaluer le premier cluster dans son ensemble ou à un niveau local pour évaluer un ou plusieurs nœuds spécifiques en tant que ressources potentielles du premier cluster en cas de mise en œuvre à un niveau local.
  • L’orchestrateur (202) a alors communiqué avec un autre orchestrateur (302) situé dans un second cluster (300), en lui notifiant des contraintes spécifiques pour la mise en œuvre, au niveau local du second cluster, d’une fonction d’affinité prenant en compte ces contraintes notifiées. Suite à l’obtention d’un résultat d’évaluation favorable, on suppose qu’un second nœud (330) a été identifié avec succès dans le second cluster en tant que ressource de destination. Après cela, la procédure de clonage a été mise en œuvre, répliquant le premier nœud (210) dans le second nœud (330).
  • La procédure ainsi développée en lien avec pour la réplication d’un nœud depuis un premier cluster vers un second cluster peut évidemment s’appliquer de manière analogue à la réplication de plusieurs nœuds, ou à la réplication d’un pod, ou encore à la réplication de plusieurs pods appartenant ou non initialement au même nœud source.
  • La technique proposée peut être appliqué dans une grande variété d’environnements, notamment la gestion de systèmes informatiques distribués, le déploiement de réseaux d’accès radio dans les systèmes de télécommunications, et le déploiement de configurations distribuées sur plusieurs sites, avec des acteurs et des zones multiples, et éventuellement des réplicas répartis sur plusieurs centres de données, de telles configurations étant susceptibles de supporter des ensembles fonctionnels variés.
  • Peu importe l’environnement de travail spécifique de la ressource à évaluer – qu’il s’agisse d’un nœud unique, d’un ensemble de serveurs, d’une zone géographique spécifique ou d’un sous-réseau IP – la technique proposée est conçue pour s’adapter à ces différents contextes.
  • Bien que la technique proposée ait été décrite en détail avec référence à certaines formes de réalisation préférées, diverses modifications et variations peuvent être apportées sans s’écarter du domaine de l’invention tel que défini dans les revendications jointes. Par exemple, les procédures décrites peuvent être effectuées dans un ordre différent, des éléments peuvent être ajoutés ou supprimés, et des caractéristiques de différents modes de réalisation peuvent être combinées comme il convient.
    •

Claims (12)

  1. Module dans un environnement informatique en nuage,
    le module étant adapté pour opérer sur un système de traitement de données comprenant un ensemble de ressources (210, 212, 220, 230, 310, 320, 330),
    l’ensemble de ressources comprenant une ressource source (212, 220) intervenant pour un déploiement initial d’un service,
    le module étant configuré pour :
    évaluer (110), au sein de l’ensemble de ressources, au moins une ressource potentielle (210, 212, 220, 230, 310, 320, 330) pour un nouveau déploiement du service à l’aide d’une fonction d’affinité tenant compte d’au moins une contrainte relative à une topologie de données associées au service et/ou à une architecture du système de traitement de données, et
    lorsqu’un résultat d’évaluation d’une ressource potentielle est favorable, identifier (112) la ressource potentielle comme ressource de destination pour une mise en œuvre d’une opération de clonage aboutissant au nouveau déploiement du service.
  2. Module selon la revendication 1, configuré en outre pour actualiser la topologie des données en lien avec le nouveau déploiement du service.
  3. Module selon la revendication 2, configuré en outre pour transmettre un message de mise à jour concernant la topologie des données actualisée et/ou une configuration du nouveau déploiement du service vers au moins un module tiers.
  4. Module selon la revendication 2 ou 3, configuré en outre pour collaborer avec un orchestrateur pour mettre à jour un routage conformément à la topologie des données actualisée et au nouveau déploiement du service suite à l’opération de clonage.
  5. Module selon l’une des revendications 1 à 4, dans lequel la topologie des données renseigne sur un voisinage de chaque donnée couramment associée au service.
  6. Module selon l’une des revendications 1 à 5, dans lequel ladite au moins une contrainte comprend au moins une contrainte parmi une contrainte de latence, une contrainte de bande passante, une contrainte de charge, une contrainte de coût, une contrainte d’isolation, une contrainte de sécurité, une contrainte de potentiel d’accès, une contrainte de localisation géographique de la ressource potentielle et une contrainte de non-chevauchement de la ressource de destination et d’une ressource mémoire du système de traitement de données.
  7. Système de traitement de données comprenant un module selon l'une des revendications 1 à 6.
  8. Système selon la revendication 7, dans lequel le système est à accès mémoire non uniforme, NUMA.
  9. Système selon la revendication 7 ou 8, comprenant un orchestrateur configuré pour requérir l’identification de la ressource de destination par le module et diriger l'opération de clonage.
  10. Système selon l’une des revendications 7 à 9, comprenant en outre un gestionnaire configuré pour gérer l’ensemble de ressources et mettre à jour la topologie des données en liaison avec le module.
  11. Procédé mis en œuvre par un module dans un environnement informatique en nuage, le module étant adapté pour opérer sur un système de traitement de données, comprenant un ensemble de ressources (210, 212, 220, 230, 310, 320, 330), l’ensemble de ressources comprenant une ressource source (212, 220) intervenant pour un déploiement initial d’un service,
    le procédé comprenant :
    évaluer (110), au sein de l’ensemble de ressources, au moins une ressource potentielle (210, 212, 220, 230, 310, 320, 330) pour un nouveau déploiement du service à l’aide d’une fonction d’affinité tenant compte d’au moins une contrainte relative à une topologie de données associées au service et/ou à une architecture du système de traitement de données, et
    lorsqu’un résultat d’évaluation d’une ressource potentielle est favorable, identifier (112) la ressource potentielle comme ressource de destination pour une mise en œuvre d’une opération de clonage aboutissant au nouveau déploiement du service.
  12. Programme d’ordinateur comprenant des instructions qui, lorsque le programme est mis en œuvre par un processeur, conduisent à mettre en œuvre le procédé selon la revendication 11.
EP24773065.8A 2023-10-04 2024-09-20 Module, procédé et programme utilisant une contrainte d'affinité de données pour un déploiement de service Pending EP4789094A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2310610A FR3153916A1 (fr) 2023-10-04 2023-10-04 Module, procédé et programme utilisant une contrainte d’affinité de données pour un déploiement de service
PCT/EP2024/076396 WO2025073502A1 (fr) 2023-10-04 2024-09-20 Module, procédé et programme utilisant une contrainte d'affinité de données pour un déploiement de service

Publications (1)

Publication Number Publication Date
EP4789094A1 true EP4789094A1 (fr) 2026-08-12

Family

ID=89068389

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24773065.8A Pending EP4789094A1 (fr) 2023-10-04 2024-09-20 Module, procédé et programme utilisant une contrainte d'affinité de données pour un déploiement de service

Country Status (3)

Country Link
EP (1) EP4789094A1 (fr)
FR (1) FR3153916A1 (fr)
WO (1) WO2025073502A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2306267A1 (fr) 1975-04-02 1976-10-29 Toshin Steel Co Four de production d'aciers a partir de dechets d'acier et similaires
US10785122B2 (en) * 2018-10-05 2020-09-22 Cisco Technology, Inc. Canary release validation mechanisms for a containerized application or service mesh
EP4180958B1 (fr) * 2021-11-16 2026-03-25 Intel Corporation Stockage informatique dans une architecture de fonction en tant que service

Also Published As

Publication number Publication date
FR3153916A1 (fr) 2025-04-11
WO2025073502A1 (fr) 2025-04-10

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20260403

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR