FR 3153916 A1 20250411 FR 2310610 A 20231004 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.. Figure de l’abrégé : Figure 1 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 FIG. 1 illustre un processus de gestion de ressources et de clonage selon un exemple de réalisation. Fig. 2 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 FIG. 3 représente un exemple d’état final du système de FIG. 2 après la mise en œuvre d’un processus de clonage, reflétant des changements dans les clusters. Fig. 4 Fig. 5 FIG. 4 et FIG. 5 représentent, chacun, un autre exemple d’état final du système de FIG. 2 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. FIG. 1 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 ( Ressource B : Latence moyenne (25µs) + Pas de chevauchement = Score total moyen. Ressource C : Latence faible ( 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 FIG. 1 . 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 FIG. 1 . 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. FIG. 2 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. FIG. 3 représente un état final de l’un des clusters (200) de FIG. 2 à 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). FIG. 4 représente un autre état final de l’un des clusters (200) de FIG. 2 à 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). FIG. 5 représente un autre état final des clusters (200, 300) de FIG. 2 à 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 FIG. 5 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. 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. Module selon la revendication 1, configuré en outre pour actualiser la topologie des données en lien avec le nouveau déploiement du service. 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. 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. 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. 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. Système de traitement de données comprenant un module selon l'une des revendications 1 à 6. Système selon la revendication 7, dans lequel le système est à accès mémoire non uniforme, NUMA. 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. 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. 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. 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.