FR 3150611 A1 20250103 FR 2306779 A 20230628 Procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service . L’invention se rapporte à un procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N:B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation. Selon ce procédé, une décision d’ajouter ou de retirer une unité de virtualisation (UV) à un ensemble ( set ) d’unités de virtualisation instanciées pour la mise en œuvre dudit service est effectuée en fonction : - du nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection ; - d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale PLmax autorisée par unité de virtualisation (UV) dudit ensemble ( set ). Figure d’abrégé : Figure 4 Procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service. L’invention se situe dans le domaine de la répartition de charge sur un ensemble de ressources informatiques. Plus particulièrement la présente invention concerne les mécanismes de mise à l’échelle horizontale, selon lesquels un nombre de ressources déployées pour la mise en œuvre d’un service est adapté automatiquement en fonction de la charge de service à absorber. Art antérieur De nombreux réseaux de communication utilisent des fonctions virtualisées instanciées sur des nœuds de virtualisation hébergés dans des machines virtuelles ou dans des serveurs regroupés en grappes, ou « clusters » au sein de centres de données. Dans la suite du document, il est fait mention de nœuds de virtualisation hébergés dans des serveurs mais il est entendu que l’enseignement du présent document s’applique également au cas de nœuds de virtualisation hébergés dans des machines virtuelles. Un exemple de gestion d’instanciation de fonctions virtualisées est connu sous l’appellation « Kubernetes® ». Une architecture « Kubernetes® » comprend au moins une grappe de nœuds de virtualisation. Une telle grappe de nœuds de virtualisation comprend au moins un premier nœud dit nœud de gestion, ou « Kubernetes® master node », et une pluralité de nœuds de calcul, ou « Kubernetes® worker node » destinés à instancier des fonctions virtualisées. Le nœud de gestion comprend, entre autres, une base de données dite ETCD qui consiste en un registre dynamique de configuration des nœuds de calculs. Un nœud de calcul comprend une pluralité d’unités de virtualisation ou « pods ». Chaque unité de virtualisation est dotée de ressources permettant l’exécution d’une ou plusieurs tâches. Une tâche, lorsqu’elle est exécutée, contribue à la mise en œuvre d’un service ou d’une fonction virtualisée. Une architecture « Kubernetes® » intègre par ailleurs divers mécanismes de répartition de charge, dont un mécanisme connu sous le nom de « Horizontal Pod Autoscaling » , qui permet d’adapter automatiquement le nombre d’unités de virtualisation installées sur l’ensemble des nœuds de virtualisation en fonction d’un niveau de charge courant associé au service à mettre en œuvre, c’est-à-dire un niveau de charge courant qu’il convient d’être en capacité d’absorber afin de garantir une qualité satisfaisante du service fourni. Ainsi, en réponse à une augmentation de la charge, un nombre plus important d’unités de virtualisation est déployé (dans une opération dite de « scale out »). À l’inverse, en réponse à une diminution de la charge, des unités de virtualisation devenues inutiles sont retirées (dans une opération dite de « scale in »), afin par exemple de les rendre disponibles pour la mise en œuvre d’un autre service, mais également pour des considérations d’économie énergétique. On décrit de manière simplifiée, en relation avec la , une architecture classique « Kubernetes® », permettant la mise en œuvre d’un tel mécanisme. Comme décrit précédemment, dans une telle architecture, un nombre R (dit « Replicas ») d’unités de virtualisation UV est déployé sur un ou plusieurs nœuds de virtualisation, pour la mise en œuvre d’un service. Un module sonde Mod_S mesure un usage CPU moyen (i.e. un usage CPU, ou usage processeur, des serveurs informatiques sur lesquelles elles sont déployées) par unité de virtualisation, sur l’ensemble set des unités de virtualisation UV instanciées. Au niveau d’un module de mise à l’échelle automatique Mod_ME (« Autoscaler ») cet usage CPU moyen d’une unité de virtualisation est comparé à une valeur seuil exprimée sous la forme d’un ratio de 0% à 100% (« targets ») d’une valeur CPU nominale garantie pour chaque unité de virtualisation (« requests »). Cette valeur CPU nominale garantie « requests » a été réservée au moment de l’installation de l’unité de virtualisation sur son nœud de virtualisation. Le résultat de cette comparaison est utilisé pour adapter le nombre R de replicas instanciés. Par exemple, si l’usage CPU moyen par unité de virtualisation dépasse la valeur seuil targets.requests , une décision est transmise à un module d’installation Mod_INS d’augmenter le nombre R de replicas, c’est-à-dire d’augmenter le nombre d’unités de virtualisation UV instanciées pour la mise en œuvre du service. Le nombre d’unités de virtualisation que le module de mise à l’échelle Mod_ME peut décider de déployer est toutefois borné entre une limite basse « MINPODS » et une limite haute « MAXPODS » prédéfinies. Un module de répartition de charge Mod_LB répartit la charge de service SL sur l’ensemble des R unités de virtualisation disponibles. À titre illustratif et non limitatif, cette charge de service SL peut être définie comme un nombre de requêtes de service par seconde, dans ce cas, le module de répartition de charge Mod_LB relaie une portion 1/ R des requêtes de service sur chacune des R unités de virtualisation. Dans un autre exemple, la charge de service peut aussi être définie comme un débit de paquets Internet devant être émis par les unités de virtualisation, dans ce cas, le module de répartition de charge Mod_LB relaie les requêtes de service sur chacune des R unités de virtualisation de sorte que le débit de paquets Internet émis par chacune des unités de virtualisation se rapproche du ratio 1/ R du débit total de paquets Internet émis par l’ensemble des unités de virtualisation. Le processus de dimensionnement mis en œuvre (i.e. l’adaptation du nombre de réplicas) est ainsi régi par une règle pouvant être formalisée sous la forme de l’équation suivante : avec - R(k) le nombre d’unités de virtualisation instanciées à un instant k ; - R(k+1) le nombre d’unités de virtualisation à instancier à un instant k + 1 , postérieur audit instant k ; - usage p l’usage CPU mesuré par le module sonde pour l’unité de virtualisation p entre l’instant k et l’instant k+ 1 ; - ceil la fonction d’arrondi à l’entier supérieur ; - et les contraintes supplémentaires, non formalisées dans l’équation (1) mais mises en œuvre, selon lesquelles R(k+1) est automatiquement fixé à la valeur MINPODS si le résultat de l’équation (1) devient inférieur à MINPODS , et R(k+1) est automatiquement fixé à la valeur MAXPODS si le résultat de l’équation (1) devient supérieur à MAXPODS . La illustre sur un exemple les effets du mécanisme de mise à l’échelle précédemment décrit, dans une configuration dans laquelle targets est fixé à 100%, MINPODS à 1, et MAXPODS à 4. Comme MINPODS est fixé à 1, au minimum une unité de virtualisation est instanciée. Lorsque la charge de service (en abscisse) augmente et dépasse la charge maximale (seuil targets.requests , ici égal à requests ) définie pour une unité de virtualisation (franchissement de l’abscisse de valeur 1), une nouvelle unité de virtualisation est instanciée (le nombre de réplica R passe de 1 à 2). Lorsque la charge de service augmente encore et dépasse la charge maximale définie pour deux unités de virtualisation (franchissement de l’abscisse de valeur 2), une nouvelle unité de virtualisation est instanciée (le nombre de réplica R passe de 2 à 3). De telles opérations de « scale out » peuvent être répétées pour adapter automatiquement le nombre d’unités de virtualisation instanciées à un niveau de charge croissant, jusqu’à ce que le nombre maximal d’unités de virtualisation défini par MAXPODS (ici quatre), soit atteint. À l’inverse, lorsque la charge de service diminue, à chaque franchissement à la baisse d’une unité en abscisse, le retrait d’une unité de virtualisation est mis en œuvre. De telles opération de « scale in » peuvent être répétées pour adapter automatiquement le nombre d’unités de virtualisation instanciées à un niveau de charge décroissant, jusqu’à ce que le nombre minimal d’unités de virtualisation défini par MINPODS (ici un), soit atteint. La configuration illustrée en relation avec la ne permet toutefois pas de pallier de manière rapide une éventuelle défaillance d’une unité de virtualisation. Par exemple, comme illustré sur cette par la flèche D, en cas de défaillance d’une unité de virtualisation parmi trois unités de virtualisation en service, la charge de service est répartie sur les deux unités de virtualisation restantes encore fonctionnelles, mais la charge moyenne supportée par ces deux unités devient supérieure à la charge maximale qu’elles peuvent absorber (dépassement du seuil targets.requests en ordonnées), et la fourniture du service attendu n’est donc plus garantie (risque de ralentissement, de coupures, etc.), le système étant devenu sous-dimensionné du fait de la défaillance. Cette situation perdure le temps que « Kubernetes® » met à réinstancier une unité de virtualisation alternative à l’unité défaillante. Plusieurs causes peuvent retarder l’instanciation d’une unité alternative. Le choix du nœud de virtualisation peut être par exemple retardé par manque de ressources sur les nœuds de virtualisation existants et la nécessité d’attendre l’installation d'un nouveau nœud de virtualisation. Le téléchargement de l’image de l’unité de virtualisation sur le nœud de virtualisation choisi pour l’héberger peut par exemple être également retardé à cause d’une surcharge du réseau, etc. Une solution classique à ce problème consiste à adopter un schéma de protection selon lequel pour N unités de virtualisation nécessaires pour absorber une charge dans des conditions nominales (i.e. sans défaillance), on prévoit B unités de virtualisation supplémentaires (schéma de protection de type N:B) permettant de palier jusqu’à un nombre prédéterminé d’éventuelles défaillances sans que la qualité de service soit dégradée, et donc de manière transparente pour l’utilisateur. Les paramètres targets , MINPODS et MAXPODS sont alors adaptés en fonction du schéma de protection souhaité. La illustre ce mécanisme sur l’exemple d’un schéma de protection 4:1. Dans une telle configuration, MINPODS est fixé à 2 et targets à 50%, ce qui permet de garantir qu’au moins deux unités de virtualisation sont déployées, et qu’en cas de défaillance d’une unité de virtualisation dans la situation la moins favorable, c’est-à-dire lorsque deux unités de virtualisation seulement sont déployées, l’unité de virtualisation encore fonctionnelle reste en mesure d’absorber la totalité de la charge de service auparavant répartie sur les deux unités. MAXPODS est par ailleurs fixé à 5, afin d’obtenir une charge de service garantie correspondant la charge totale pouvant être absorbée par quatre unités de virtualisation dans des conditions nominales, et ceci même en cas de défaillance d’une unité de virtualisation. Le mécanisme de protection précédemment décrit est donc efficace en ce qu’il permet d’éviter que le système se retrouve ponctuellement sous dimensionné par rapport à une charge à absorber, en cas de défaillance d’un nombre prédéterminé d’unités de virtualisation. Une telle solution n’est cependant pas optimale sur le plan de l’efficacité énergétique. En effet, comme visible sur la , elle conduit à des surdimensionnements ponctuels du système, conséquences du fait que la valeur targets est fixée pour garantir le service dans le cas le plus défavorable, et qu’elle reste donc constante quel que soit le nombre d’unités de virtualisation déployées. Ainsi, on constate par exemple sur cette que le passage de trois à quatre unités de virtualisation est réalisé de manière très précoce, alors qu’il aurait pu survenir plus tardivement, idéalement au niveau de l’abscisse de valeur 2, sans que cela remette en cause la capacité du système à garantir le service même en cas de défaillance d’une unité de virtualisation. Autrement dit, bien qu’efficaces pour assurer une adaptation du nombre d’unités de virtualisation à déployer en fonction d’une évolution d’une charge de service, ainsi qu’une protection selon un schéma de protection prédéfini, les moments de déclenchement des opérations de « scale in » (retrait d’une unité de virtualisation en cas de baisse de charge) et de « scale out » (ajout d’une unité de virtualisation en cas de hausse de charge) ne sont clairement pas optimisés en termes de vue performance énergétique avec les solutions actuelles (les opérations de « scale out » étant déclenchées de manière trop précoce et les opérations de « scale in » de manière trop tardive, pour la quasi-totalité d’entre-elles). D’un point de vue plus global, à l’heure où la réduction des émissions de gaz à effet de serre est devenue un enjeu capital pour lutter contre le réchauffement climatique à l’échelle planétaire, les mécanismes existants de dimensionnement automatique des systèmes informatiques en réponse à l’évolution d’une charge de service restent largement perfectibles sur les aspects d’économies de ressources, tant énergétiques que matérielles. Par exemple lorsque d’anciens serveurs informatiques sont réutilisés comme nœuds de virtualisation à côté de serveurs informatiques plus récents, les performances hétérogènes ne permettent pas de garantir que les B unités de virtualisations réparties sur des serveurs informatiques de performance différente des de celle serveurs informatiques sur lesquels les N unités de virtualisation nominales sont hébergées puissent pallier la défaillance de B unités parmi les N unités de virtualisation nominales. La présente invention a pour objet de résoudre tout ou partie des inconvénients précédemment cités. La présente technique permet de proposer une solution visant à remédier à certains inconvénients de l’art antérieur. Selon un aspect, la présente technique se rapporte en effet à un procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N:B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation. Selon le principe général de la technique proposée, une décision d’ajouter ou de retirer une unité de virtualisation à un ensemble d’unités de virtualisation instanciées pour la mise en œuvre dudit service est effectuée en fonction : - du nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection ; - d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale P L max autorisée par unité de virtualisation dudit ensemble. De cette manière, contrairement aux solutions de l’art antérieur, le déclenchement d’une décision d’ajouter ou de retirer une unité de virtualisation est optimisé en termes de performances énergétiques, en ce qu’il prend non seulement en compte le nombre B d’unités de virtualisation de sauvegarde prévus dans le cadre du schéma de protection visé, mais également en ce qu’il repose sur l’évaluation d’une charge de service plutôt que d’une charge CPU, i.e. sur une donnée complètement indépendante d’une charge CPU à vide résiduelle potentiellement présente au niveau des unités de virtualisation. Dans un mode de réalisation particulier, ladite décision d’ajouter ou de retirer une unité de virtualisation est régie par la formule : avec - R(k) le nombre d’unités de virtualisation instanciées à un instant k ; - R(k+1) le nombre d’unités de virtualisation à instancier à un instant k + 1 , postérieur audit instant k ; - PL p la charge de service atteinte au niveau d’une unité de virtualisation p dudit ensemble entre l’instant k et l’instant k+1 , dite charge de service courante. De cette manière, les déclenchements de scale out et de scale in à un même niveau – i.e. d’un nombre M à M+1 unités de virtualisation lors d’une l’augmentation de la charge de service ou d’un nombre M+1 à M unités de virtualisation lors d’une baisse de la charge de service – surviennent pour les mêmes valeurs de charge de Service SL, garantissant ainsi une efficacité énergétique optimale. Dans un mode de réalisation particulier, ladite charge de service PLmax maximale autorisée par unité de virtualisation est estimée automatiquement en fonction d’au moins une donnée de comparaison entre une charge de service courante atteinte au niveau d’au moins une unité de virtualisation et une charge CPU résultante de ladite charge de service courante atteinte au niveau de ladite au moins une unité de virtualisation. De manière alternative, dans un autre mode de réalisation particulier, ladite charge de service PLmax maximale autorisée par unité de virtualisation est estimée automatiquement en fonction d’au moins une donnée de comparaison entre une charge de service courante atteinte au niveau d’au moins une unité de virtualisation et au moins un paramètre de qualité de service prédéterminé associé à ladite au moins une unité de virtualisation. De cette manière, la technique proposée peut être mise en œuvre de manière simple et automatique, sans modifications majeures du module de mise à l’échelle d’une architecture « Kubernetes® », une charge de service pouvant être rapportée dans un format proche d’une charge CPU. Selon une caractéristique particulière de ce mode de réalisation, ledit au moins un paramètre de qualité de service comprend un temps de réponse audit service, représentatif d’un temps de traitement d’une requête de service sur ladite au moins une unité de virtualisation. Dans un mode de réalisation particulier, une sélection, parmi une pluralité de nœuds de virtualisation disponibles au sein de ladite infrastructure de virtualisation, d’un nœud de virtualisation cible au sein duquel une unité de virtualisation est ajoutée ou retirée en réponse à ladite décision tient compte d’au moins une caractéristique technique associée auxdits nœuds de virtualisation de ladite pluralité. De cette manière, la présente technique peut être mise en œuvre même au sein d’architecture « Kubernetes® » reposant sur la mise en œuvre de serveurs informatiques aux caractéristiques techniques hétérogènes, dans la mesure où ces caractéristiques sont prises en compte pour la sélection d’un nœud de virtualisation sur lequel ajouter ou retirer une unité de virtualisation lors de l’adaptation du dimensionnement de l’infrastructure de virtualisation à l’évolution d’une charge de service. Dans un mode de réalisation particulier, ladite au moins une caractéristique technique comprend une fréquence d’horloge de fonctionnement associée à au moins un nœud de virtualisation de ladite pluralité. De cette manière, on dispose d’un moyen simple, par la connaissance de telles fréquences d’horloge, de comparer par unité de temps les capacités de traitement des différents nœuds de virtualisation disponibles pour l’ajout ou le retrait d’une unité de virtualisation. Selon une caractéristique particulière, ladite fréquence d’horloge de fonctionnement associée à au moins un nœud de virtualisation de ladite pluralité est communiquée à un module d’orchestration en charge de ladite sélection, dans une étape d’enrôlement dudit nœud de virtualisation auprès dudit module d’orchestration, en complément d’une capacité totale de traitement CPU associée audit nœud de virtualisation. De cette manière, le module d’orchestration est à même de comparer les capacités de traitement des différents nœuds de virtualisation, même lorsque ceux-ci sont mis en œuvre sur des dispositifs électroniques aux caractéristiques techniques hétérogènes. Dans un mode de réalisation particulier, ladite fréquence d’horloge de fonctionnement est utilisée pour normaliser une capacité de traitement CPU à réserver à une unité de virtualisation au sein dudit nœud de virtualisation cible, par application d’un facteur de normalisation. Selon une caractéristique particulière, ledit facteur de normalisation est défini par un ratio entre ladite fréquence d’horloge de fonctionnement et une fréquence d’horloge de référence prédéfinie, commune à l’ensemble des nœuds de virtualisation de ladite pluralité. De cette manière, par l’utilisation d’un tel facteur de normalisation, la comparaison des capacités de traitement des différents nœuds de virtualisation et l’obtention de capacités de traitement normalisées sont encore simplifiées. Selon un autre aspect, la présente technique se rapporte également à un système d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N :B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation. Selon la technique proposée, un tel système comprend un module de mise à l'échelle configuré pour délivrer une décision d’ajouter ou de retirer une unité de virtualisation à un ensemble d’unités de virtualisation instanciées pour la mise en œuvre dudit service, ladite décision étant effectuée en fonction : - du nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection ; - d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale P L max autorisée par unité de virtualisation dudit ensemble. Un tel système comprend par ailleurs, dans divers modes de réalisation particuliers, des moyens lui permettant de mettre en œuvre les caractéristiques du procédé précédemment décrits dans l’un quelconque de ses modes de réalisation, avec les mêmes avantages. Selon un autre aspect, la technique proposée se rapporte également à un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, comprenant des instructions de code de programme pour l’exécution d'un procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, tel que décrit précédemment dans l’un quelconque de ses modes de réalisation, lorsqu’il est exécuté sur un ordinateur. La technique proposée vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé tel que décrit précédemment, dans l’un quelconque de ses modes de réalisation. Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur. D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau, par exemple le réseau Internet. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention. Figures D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : [Fig 1 présente de manière schématique les différents modules d’une architecture « Kubernetes® », et leurs entrées-sorties, selon l’art antérieur ; illustre un exemple des effets de la mise en œuvre d’un mécanisme de mise à l’échelle horizontale au sein d’une architecture « Kubernetes® » sans schéma de protection, selon l’art antérieur ; [ illustre un exemple des effets de la mise en œuvre d’un mécanisme de mise à l’échelle horizontale au sein d’une architecture « Kubernetes® » implémentant un schéma de protection, selon l’art antérieur ; présente de manière schématique les différents modules d’une architecture « Kubernetes® » modifiée, et leurs entrées-sorties, dans un mode de réalisation particulier de la technique proposée ; illustre un exemple de phénomènes indésirables d’hystérésis associés aux solutions de l’art antérieur en cas de charge à vide importante, que la présente technique vise à supprimer ; illustre un exemple des effets de la mise en œuvre d’un mécanisme de mise à l’échelle horizontale au sein d’une architecture « Kubernetes® » modifiée selon la présente technique ; présente un diagramme de séquence illustrant les mécanismes de sélection d’un nœud de virtualisation et de réservation de capacité de traitement pour une unité de virtualisation, tels que mis en œuvre de manière classique au sein d’une architecture « Kubernetes® » selon l’art antérieur ; présente un diagramme de séquence illustrant les mécanismes de sélection d’un nœud de virtualisation et de réservation de capacité de traitement pour une unité de virtualisation, tels que mis en œuvre dans un mode de réalisation particulier de la technique proposée ; présente de manière schématique les différents modules d’une architecture « Kubernetes® » modifiée, et leurs entrées-sorties, dans un autre mode de réalisation particulier de la technique proposée ; décrit une architecture simplifiée d’un système électronique pour la mise en œuvre de la technique proposée, dans un mode de réalisation particulier. Description détaillée de l’invention La technique décrite ci-après permet de remédier à certains des inconvénients précités. Sur toutes les figures du présent document, les éléments et étapes de même nature sont désignés par une même référence numérique. Selon un premier aspect, la présente technique se rapporte à un procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service. La technique proposée se rapporte plus particulièrement à des perfectionnements du mécanisme classique de mise à l’échelle automatique horizontale (« Horizontal Pod Autoscaling » ) d’une architecture « Kubernetes® » implémentant un schéma de protection N:B, visant à en améliorer la performance énergétique. On présente de manière schématique, en relation avec la , une architecture « Kubernetes® » modifiée selon la présente technique. Par rapport à l’architecture « Kubernetes® » classique tel que précédemment décrite en relation avec la , la présente technique repose dans son principe général sur une combinaison de deux modifications principales visant à optimiser le déclenchement, par un module de mise à l'échelle (« Autoscaler »), d’une décision d’ajouter ou de retirer une unité de virtualisation à un ensemble d’unités de virtualisation instanciées pour la mise en œuvre d’un service. Ces modifications comprennent, au niveau dudit module de mise à l'échelle : - d’une part la prise en compte du nombre B d’unités de virtualisation de sauvegarde prévues dans le schéma de protection mis en œuvre ; - d’autre part la mise en œuvre d’une comparaison basée non plus sur une charge CPU, mais sur une charge de service. Plus particulièrement, la mise en œuvre de ces modifications nécessite plusieurs adaptations conjointes de l’architecture « Kubernetes® », illustrées sur la dans un mode de réalisation particulier de la technique proposée et présentées ci-après. Selon une première adaptation, le nombre B d’unités de virtualisation de sauvegarde prévues dans le schéma de protection mis en œuvre est fourni en entrée du module de mise à l’échelle. Selon une deuxième adaptation, le module sonde est modifié afin qu’il mesure non plus une charge CPU des unités de virtualisation, mais une charge de service PL p atteinte au niveau des unités de virtualisation. Selon une troisième adaptation, une nouvelle valeur seuil de référence PL max est fournie en entrée du module de mise à l’échelle, correspondant une charge de service maximale tolérée par unité de virtualisation, cette nouvelle valeur de seuil PL max se substituant à la valeur de seuil « targets.requests » - i.e. au pourcentage de la charge CPU réservée par Pod – utilisée dans l’architecture « Kubernetes® » classique de l’art antérieur. Selon une caractéristique particulière, la charge de service maximale admissible PL max est par exemple estimée automatiquement en fonction d’une comparaison entre une charge de service courante atteinte au niveau d’une ou plusieurs unités de virtualisation et une charge CPU résultante de ladite charge de service courante sur la ou les unités de virtualisation considérées. Selon une autre caractéristique particulière, de manière alternative, la charge de service maximale admissible PL max est par exemple estimée automatiquement en fonction d’une comparaison entre une charge de service courante atteinte au niveau d’une ou plusieurs unités de virtualisation et au moins un paramètre de qualité de service prédéterminé. À titre illustratif et non limitatif, un tel paramètre de qualité de service prédéterminé correspond par exemple à un temps de réponse au service, représentatif d’un temps de traitement d’une requête de service sur la ou les unités de virtualisation considérées. La nouvelle formule pour calculer le seuil de déclenchement d’une opération de mise à l'échelle consiste à calculer la somme des charges de service de chaque unité de virtualisation et à la diviser par la charge de service maximale PL max acceptée par unité de virtualisation, à arrondir le résultat obtenu à l’entier supérieur, et à y ajouter la quantité B d’unités de virtualisation prévues dans le schéma de protection visé, selon la formule suivante : (2) Avec : - R(k) le nombre d’unités de virtualisation instanciées à un instant k ; - R(k+1) le nombre d’unités de virtualisation à instancier à un instant k + 1 , postérieur audit instant k ; - ceil la fonction d’arrondi à l’entier supérieur ; - et les contraintes supplémentaires, non formalisées dans l’équation (2) mais toujours mises en œuvre, selon lesquelles R(k+1) est automatiquement fixé à la valeur MINPODS si le résultat de l’équation (2) devient inférieur à MINPODS , et R(k+1) est automatiquement fixé à la valeur MAXPODS si le résultat de l’équation (2) devient supérieur à MAXPODS . Une telle implémentation selon la technique proposée est avantageuse sur de nombreux plans. En premier lieu, elle peut être mise en œuvre sans modifications majeures du module de mise à l’échelle d’une architecture « Kubernetes® », dans la mesure où une charge de service peut être rapportée dans un format proche d’une charge CPU. En deuxième lieu, elle permet de rendre les décisions de mise à l’échelle – i.e. le déclenchement de l’ajout ou du retrait d’une unité de virtualisation – indépendante de la charge CPU à vide des unités de virtualisation. Par charge à vide (également désignée sous le terme « noload » dans l’ensemble des figures), on entend ici une charge CPU résiduelle sur les unités de virtualisation plus ou moins importante, potentiellement existante même lorsque la charge de service est nulle, c’est-à-dire alors même que les unités de virtualisation ne traitent aucune donnée liée au service en question. L’inventeur a en effet mis en évidence que la charge CPU des unités de virtualisation peut varier de façon non linéaire par rapport à la charge de service qu’ils absorbent, ce phénomène étant d’autant plus accentué que la charge à vide des unités de virtualisation est importante. Aussi, l’utilisation selon l’art antérieur de la charge CPU des unités de virtualisation comme critère pour déterminer le déclenchement d’une opération de mise à l’échelle, même en adaptant ce mécanisme pour prendre en compte le nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection, entraine l’apparition de deux phénomènes d’hystérésis tels qu’illustrés de façon schématique sur la : - lorsque la charge de service (en abscisse) augmente, l’ajout d’une unité de virtualisation se produit de manière trop précoce par rapport au moment nominal en termes d’efficacité énergétique ; - lorsque la charge de service (en abscisse) diminue, le retrait d’une unité de virtualisation se produit de manière trop tardive par rapport au moment nominal en termes d’efficacité énergétique. Par ces deux phénomènes l’efficacité énergétique du mécanisme de mise à l’échelle horizontale se dégrade, et ce d’autant plus que la charge à vide est importante. La combinaison des deux modifications principales d’une architecture « Kubernetes® » telle que proposée selon le principe général de la présente technique – i.e. la prise en compte du nombre d’unités de virtualisation de sauvegarde d’une part, et l’utilisation de la charge de service plutôt que de la charge CPU d’autre part, en tant que critères de décision des opérations de mise à l’échelle – est donc particulièrement intéressante, en ce que ces modifications sont complémentaires et synergiques afin d’atteindre une efficacité énergétique optimale. En particulier, du fait de la relation directe entre la charge de service totale SL et la charge de service prise en charge par chaque unité de virtualisation (selon la formule ), il n’y a pas d’effet d’hystérésis et les phénomènes indésirables précédemment décrits ne se produisent pas avec la technique proposée, même en cas de charge CPU à vide importante au niveau des unités de virtualisation. Comme illustré de manière schématique en relation avec la , et à la différence de la situation de la , lorsque la présente technique est mise en œuvre, les déclenchements de scale out et de scale in à un même niveau (e.g. un scale out dans lequel le nombre de replica passe de 2 à 3 unités de virtualisation, ou un scale in out dans lequel le nombre de replica passe de 3 à 2 unités de virtualisation) surviennent pour les mêmes valeurs de charge de Service SL (i.e. à la même valeur d’abscisse, au niveau d’un entier), garantissant ainsi une efficacité énergétique optimale, équivalente à la meilleure efficacité énergétique pouvant être obtenue en ce qui concerne les déclenchements des opérations de mise à l’échelle. Les différents aspects de la présente technique précédemment décrits se rapportent à la détermination du meilleur moment pour effectuer une opération de scale in ou de scale out . On s’intéresse par la suite, de manière complémentaire, à d’autres aspects de la présente technique, se rapportant au choix du nœud de virtualisation sur lequel doit être ajouté ou retiré une unité de virtualisation lors de telles opérations. Les perfectionnements associés aux modes de réalisation décrits précédemment sont efficaces tant que les unités de virtualisation d’un schéma de protection sont déployées sur des nœuds de virtualisation homogènes, c’est-à-dire présentant des caractéristiques techniques sensiblement équivalentes. En effet, un schéma de protection N:B permet de supporter la défaillance de B unités de virtualisation parmi les N unités de virtualisation prévues pour supporter la charge de service nominale, dans une situation où toutes les unités de virtualisation peuvent être considérées comme équivalentes. C’est généralement le cas lorsqu’une infrastructure de virtualisation est déployée sur des serveurs informatiques neufs, dans la plupart des cas identiques pour des raisons de coûts (il est en général moins cher d’acheter des équipements identiques en grande quantité que d’acheter des équipements aux caractéristiques techniques variées en plus petites quantités). Dans certaines situations, il arrive toutefois que les serveurs utilisés pour la mise en œuvre d’une infrastructure de virtualisation ne soient pas tous identiques en termes de caractéristiques techniques (par exemple, en cas de réutilisation dans un centre de données de serveurs informatiques d’origines diverses, par exemple en provenance de plateformes démantelées avant la fin de la période de support garanti par les vendeurs de ces serveurs informatiques). En tout état de cause, de telles situations sont amenées à être de plus en plus fréquentes, dans un contexte global d’impératif d’économies de ressources où les incitations à réexploiter des appareils existants dans des opérations de « seconde vie » plutôt qu’à en acquérir des neufs tendent à se multiplier. Les nœuds de virtualisation sur lesquels les unités de virtualisation sont susceptibles d’être instanciées exploitent alors des processeurs qui ont potentiellement des capacités de traitement différentes. Il est donc proposé, dans un mode de réalisation de la présente technique, de tenir compte d’au moins une caractéristique technique associée aux nœuds de virtualisation disponibles, lors de la sélection d’un nœud de virtualisation au sein duquel une unité de virtualisation est ajoutée ou retirée en réponse à une décision de mise à l’échelle automatique. Dans un mode de réalisation, ladite caractéristique technique est la fréquence d’horloge de fonctionnement desdits nœuds de virtualisation, potentiellement différente d’un nœud à un autre. Pour faciliter la compréhension de la problématique qui se pose en présence de nœuds aux caractéristiques techniques hétérogènes et la solution proposée, on décrit ci-après, en relation avec la , la séquence connue qui permet, dans le cadre d’une architecture « Kubernetes® » classique, de réserver pour chaque unité de virtualisation la capacité de traitement « requests » déjà introduite en relation avec l’art antérieur, exprimée en portion de CPU. On peut considérer qu’une telle capacité de traitement correspond à une fraction de temps, ou bien encore à une fraction du nombre de cycles d’horloge réservables par unité de temps. Dans une étape préliminaire 71, lors de son enrôlement au sein d’une grappe (ou « cluster ») de nœuds de virtualisation, chaque nœud de virtualisation (par exemple le nœud i de virtualisation « Node_i » illustré sur la ) fournit à un module d’orchestration Mod_ORC (ou « scheduler ») sa capacité totale « total_CPU_i » de traitement CPU (à noter que pour des raisons de simplification, le module d’orchestration, bien qu’existant, n’a pas été représenté sur les figures 1 et 4 précédemment décrites, son fonctionnement et ses interactions avec les autres modules n'étant pas modifié dans les modes de réalisation précédemment décrits). Avant toute réservation de temps de traitement sur le nœud i, cette capacité totale « total_CPU_i » de traitement CPU correspond à une capacité de traitement disponible « Available_CPU_i » sur le nœud. Ultérieurement, lorsqu’une décision de scale out est prise par le module de mise à l’échelle Mod_ME, celui-ci transmet, dans une étape 72, une demande d’instanciation d’une nouvelle unité de virtualisation à un module d’installation Mod_INS. Le module d’installation Mod_INS détermine alors la capacité de traitement requise « request s » pour cette unité de virtualisation (éventuellement en calculant la somme des capacités requises pour chacun des conteneurs qui la compose), puis demande au module d’orchestration Mod_ORC, dans une étape 73, de réserver ces ressources dans le meilleur nœud possible. À cette fin, le module d’orchestration Mod_ORC présélectionne (« filtering ») les nœuds ayant suffisamment de capacité non encore réservée par d’autres unités de virtualisation déjà installées en leur sein, en comparant la capacité de traitement requise « request s » à la capacité de traitement disponible au sein des différents nœuds de virtualisation (par exemple « Available_CPU_i » pour le nœud i). Le module d’orchestration Mod_ORC effectue ensuite un classement (« scoring ») des nœuds présélectionnés selon de multiples critères, tel que le taux de charge par exemple, ce qui lui permet de déterminer le meilleur nœud pour l’instanciation de la nouvelle unité de virtualisation, et d’y réserver, dans une étape 74, la quantité « requests » de CPU requise pour cette unité de virtualisation (dans l’exemple de la , on considère que le nœud i est ainsi choisi, et le module d’orchestration Mod_ORC retire donc la quantité « request s » à la capacité de traitement disponible pour ce nœud). Le module d’orchestration Mod_ORC transmet au module d’installation Mod_INS, dans une étape 75 des informations d’identification du nœud de virtualisation choisi. Sur la base de ces informations, dans une étape 76, le module d’installation Mod_INS instancie l’unité de virtualisation sur le nœud de virtualisation choisi, et le configure de manière à ce que la portion de charge CPU « requests » reste bien toujours disponible pour cette unité de virtualisation. Dans le cas d’une infrastructure de virtualisation comprenant des nœuds de virtualisation associés à des processeurs de caractéristiques techniques différentes, les fréquences nominales de fonctionnement sont généralement différentes, un nœud N i travaillant par exemple à la fréquence Clk _i , et un nœud N j à la fréquence Clk _j . Il en résulte que le nombre de cycles par unité de temps, et donc le nombre de cycles réservables par unité de temps sont également différents entre une unité de virtualisation installé sur le nœud N i et une unité de virtualisation installée sur le nœud N j , et donc que les charge de service maximale PLmax_i et P L max_j acceptées respectivement par chacune de ces deux unités de virtualisation sont également différentes, ce qui pose un problème pour définir le paramètre P L max à fournir en entrée du module de mise à l’échelle (ce paramètre P L max ne pouvant pas être égal à la fois à P L max_i et à P L max_j ) pour la mise en œuvre du premier niveau d’amélioration décrit en relation avec les figures 4 à 6. Des modifications complémentaires de l’architecture « Kubernetes® » sont donc proposées dans un mode de réalisation particulier de la présente technique, de manière à ce que les perfectionnements précédemment proposés dans le cadre de la présente technique eu égard à l’optimisation de la performance énergétique soient également compatibles avec des infrastructures de virtualisation comprenant des processeurs de caractéristiques techniques différentes. Ces modifications, complémentaires aux modifications proposées précédentes, sont présentées en relation avec la , et consistent en des adaptations de la séquence de réservation de capacité de traitement des unités de virtualisation. Plus particulièrement, la reprend la nature et l’ordre des étapes déjà décrites en relation avec la , qui restent similaires, mais il est proposé dans certaines de ces étapes de faire intervenir un facteur de normalisation. En premier lieu, un paramètre « Clk _ref » prédéterminé est défini au niveau du module d’orchestration, afin de servir de fréquence d’horloge de référence pour comparer les fréquences d’horloge nominale des différents nœuds de virtualisation. Dans une étape préliminaire 81, pendant de l’étape 71 d’enrôlement de la , chaque nœud de virtualisation (par exemple le nœud i de virtualisation « N ode_i » illustré sur la ) fournit au module d’orchestration Mod_ORC sa fréquence d’horloge nominale de fonctionnement (« Clk_i » pour le nœud i), en plus de sa capacité totale de traitement CPU (« total_CPU_i » pour le nœud i). Avant toute réservation de temps de traitement sur nœud i, cette capacité totale « total_CPU_i » de traitement CPU correspond à une capacité de traitement disponible « Available_CPU_i » sur le nœud. Ultérieurement, lorsqu’une décision de scale out est prise par le module de mise à l’échelle Mod_ME, celui-ci transmet, dans une étape 82 similaire à l’étape 72 précédemment décrite en relation avec la , une demande d’instanciation d’une nouvelle unité de virtualisation au module d’installation Mod_INS. Comme dans l’étape 73 précédemment décrite en relation avec la , le module d’installation Mod_INS détermine alors la capacité de traitement requise pour cette unité de virtualisation (éventuellement en calculant la somme des capacités requises pour chacun des conteneurs qui la compose), puis demande au module d’orchestration Mod_ORC, dans une étape 83, de réserver ces ressources dans le meilleur nœud possible. Toutefois, à la différence du processus illustré en , le module d’orchestration Mod_ORC réalise un filtrage (« filtering ») des nœuds en comparant non pas la capacité de traitement requise « request s » à la capacité de traitement disponible au sein des différents nœuds de virtualisation (par exemple « Available_CPU_i » pour le nœud i), mais à une capacité de traitement disponible normalisée en fonction d’un ratio entre la fréquence de fonctionnement du nœud considéré et la fréquence d’horloge de référence, soit « ava i lable_CPU_i * ( Clk _i / Clk _ref ) » pour le nœud i. Le module d’orchestration Mod_ORC effectue ensuite un classement (« scoring ») des nœuds ainsi présélectionnés selon de multiples critères, tel que le taux de charge par exemple, ce qui lui permet de déterminer le meilleur nœud pour l’instanciation de la nouvelle unité de virtualisation. À la différence de l’étape 74 précédemment décrite en relation avec la , le module d’orchestration Mod_ORC réserve dans le nœud de virtualisation choisi, dans une étape 84, une quantité « requests / ( Clk _i / Clk _ref ) » de CPU requise pour cette unité de virtualisation (dans l’exemple de la , on considère que le nœud i est ainsi choisi, et le module d’orchestration Mod_ORC retire donc la quantité « request s / ( Clk _i / Clk _ref ) » à la capacité de traitement disponible pour ce nœud). Le module d’orchestration Mod_ORC transmet au module d’installation Mod_INS, dans une étape 85 pendant de l’étape 75 de la , des informations d’identification du nœud de virtualisation choisi, mais également la valeur du facteur correctif « ( Clk _i / Clk _ref ) » à appliquer à l’étape suivante. Sur la base de ces informations, dans une étape 86 pendant de l’étape 76 de la , le module d’installation Mod_INS instancie l’unité de virtualisation sur le nœud de virtualisation choisi, et le configure de manière à ce que la portion de charge CPU « requests / ( Clk _i / Clk _ref ) » reste bien toujours disponible pour cette unité de virtualisation. En d’autres termes, à chaque étape, il est procédé à une normalisation des opérations effectuées par application d’un facteur correctif (Clk_i/Clk_ref), comme mis en évidence en gras sur la . Cette normalisation a pour effet que les charges de service P L max_i et P L max_j maximales admissibles respectivement par chacune de deux unités de virtualisation i et j déployées sur des nœuds de virtualisation i et j fonctionnant à des fréquences d’horloge nominales « Clk_i » et « Clk_j » différentes restent identiques, et cohérentes par rapport à la valeur P L max fournie par configuration au module de mise à l’échelle, comme illustré en relation avec la . De cette manière, les perfectionnements proposés dans le cadre de la présente technique pour améliorer la performance énergique des opérations de mise à l’échelle peuvent être mis en œuvre non seulement sur des infrastructures de virtualisation reposant sur des équipements aux caractéristiques techniques similaires, mais également sur des infrastructures de virtualisation comprenant des équipements de caractéristiques techniques hétérogènes. Bien entendu, bien que présenté en relation avec une opération de scale out , le principe de normalisation décrit en relation avec la est également appliqué dans le cadre d’une opération de scale in , lorsqu’il s’agit de déterminer sur quel nœud de virtualisation retirer une unité de virtualisation. Selon un autre aspect, la présente technique se rapporte également à un système d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N:B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation. Un tel système comprend des moyens lui permettant de réaliser le procédé précédemment décrit dans l’un quelconque de ses modes de réalisation. Plus particulièrement, un tel système selon la présente technique comprend un module de mise à l'échelle configuré pour délivrer une décision d’ajouter ou de retirer une unité de virtualisation à un ensemble d’unités de virtualisation instanciées pour la mise en œuvre dudit service, ladite décision étant effectuée en fonction : - du nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection ; - d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale P L max autorisée par unité de virtualisation dudit ensemble. Comme illustré sur la , un tel système comprend par ailleurs, dans divers modes de réalisation particuliers, en complément du module de mise à l'échelle, divers autres modules (e.g. module sonde, module d’installation, module d’orchestration, module de répartition de charges) configurés pour permettre la mise en œuvre des caractéristiques du procédé précédemment décrits dans l’un quelconque de ses modes de réalisation, avec les mêmes avantages. La représente, de manière schématique et simplifiée, certains éléments structurels d’un tel système, dans un mode de réalisation particulier. Ce système comprend par exemple une mémoire 11 constituée d’une mémoire tampon M, une unité de traitement 12, équipée par exemple d’un microprocesseur μP, et pilotée par le programme d’ordinateur Pg 13, mettant en œuvre des étapes du procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, selon au moins un mode de réalisation de l’invention. Ainsi, ces éléments structurels sont utilisés par les différents modules précédemment décrits, de manière à optimiser la performance énergétique d’une architecture « Kubernetes® ». À l’initialisation, les instructions de code du programme d’ordinateur 13 sont chargées dans la mémoire tampon avant d’être exécutées par le processeur de l’unité de traitement 12. Pour la mise en œuvre des opérations effectuées par un module de mise à l'échelle, l’unité de traitement 12 reçoit par exemple en entrée E des informations stockées dans la mémoire 11 (e.g. des valeurs MINPODS , MAXPODS , un nombre B d’unités de virtualisation de sauvegarde, une charge de service maximale PLmax autorisée par unité de virtualisation, etc.), ainsi que des informations en provenance d’un module sonde, représentatives d’une charge de service totale atteinte SL mesurée par le module sonde. Le microprocesseur de l’unité de traitement 12 réalise alors les étapes du procédé d’adaptation du dimensionnement de l’infrastructure de virtualisation, selon les instructions du programme d’ordinateur 13. Plus particulièrement, ces opérations délivrent en sortie S une décision d’ajouter ou de retirer une unité de virtualisation à l’ensemble d’unités de virtualisation instanciées pour la mise en œuvre du service, à un moment optimal pour maximiser la performance énergétique de l’architecture « Kubernetes® ». Procédé d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N:B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation, ledit procédé étant caractérisé en ce qu’une décision d’ajouter ou de retirer une unité de virtualisation (UV) à un ensemble ( set ) d’unités de virtualisation instanciées pour la mise en œuvre dudit service est effectuée en fonction : - du nombre B d’unités de virtualisation de sauvegarde défini dans ledit schéma de protection ; - d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale P L max autorisée par unité de virtualisation (UV) dudit ensemble ( set ). Procédé selon la revendication 1, caractérisé en ce que ladite décision d’ajouter ou de retirer une unité de virtualisation est régie par la formule : avec - R(k) le nombre d’unités de virtualisation instanciées à un instant k ; - R(k+1) le nombre d’unités de virtualisation à instancier à un instant k + 1 , postérieur audit instant k ; - PL p la charge de service atteinte au niveau d’une unité de virtualisation p dudit ensemble entre l’instant k et l’instant k+1 , dite charge de service courante. Procédé selon la revendication 1, caractérisé en ce que ladite charge de service PL max maximale autorisée par unité de virtualisation est estimée automatiquement en fonction d’au moins une donnée de comparaison entre une charge de service courante atteinte au niveau d’au moins une unité de virtualisation et une charge CPU résultante de ladite charge de service courante atteinte au niveau de ladite au moins une unité de virtualisation. Procédé selon la revendication 1, caractérisé en ce que ladite charge de service PL max maximale autorisée par unité de virtualisation est estimée automatiquement en fonction d’au moins une donnée de comparaison entre une charge de service courante atteinte au niveau d’au moins une unité de virtualisation et au moins un paramètre de qualité de service prédéterminé associé à ladite au moins une unité de virtualisation. Procédé selon la revendication 4, caractérisé en ce que ledit au moins un paramètre de qualité de service comprend un temps de réponse audit service, représentatif d’un temps de traitement d’une requête de service sur ladite au moins une unité de virtualisation. Procédé selon la revendication 1, caractérisé en ce qu’une sélection, parmi une pluralité de nœuds de virtualisation disponibles au sein de ladite infrastructure de virtualisation, d’un nœud de virtualisation cible au sein duquel une unité de virtualisation est ajoutée ou retirée en réponse à ladite décision tient compte d’au moins une caractéristique technique associée auxdits nœuds de virtualisation de ladite pluralité. Procédé selon la revendication 6, caractérisé en ce que ladite au moins une caractéristique technique comprend une fréquence d’horloge de fonctionnement associée à au moins un nœud de virtualisation de ladite pluralité. Procédé selon la revendication 7, caractérisé en ce que ladite fréquence d’horloge de fonctionnement associée à au moins un nœud de virtualisation de ladite pluralité est communiquée à un module d’orchestration (Mod_ORC) en charge de ladite sélection, dans une étape d’enrôlement dudit nœud de virtualisation auprès dudit module d’orchestration, en complément d’une capacité totale de traitement CPU associée audit nœud de virtualisation. Procédé selon la revendication 8, caractérisé en ce que ladite fréquence d’horloge de fonctionnement est utilisée pour normaliser une capacité de traitement CPU à réserver à une unité de virtualisation au sein dudit nœud de virtualisation cible, par application d’un facteur de normalisation. Procédé selon la revendication 9, caractérisé en ce que ledit facteur de normalisation est défini par un ratio entre ladite fréquence d’horloge de fonctionnement et une fréquence d’horloge de référence (Clk_ref) prédéfinie, commune à l’ensemble des nœuds de virtualisation de ladite pluralité. Système d’adaptation du dimensionnement d’une infrastructure de virtualisation à une charge de service, ladite infrastructure de virtualisation implémentant un schéma de protection N:B dans lequel pour N unités de virtualisation absorbant ladite charge de service dans un mode nominal, il existe B unités de virtualisation de sauvegarde permettant de garantir une absorption de ladite charge de service en cas de défaillance d’au plus B unités de virtualisation, ledit système étant caractérisé en qu’il comprend un module de mise à l'échelle (Mod_ME) configuré pour délivrer une décision d’ajouter ou de retirer une unité de virtualisation (UV) à un ensemble ( set ) d’unités de virtualisation instanciées pour la mise en œuvre dudit service, ladite décision étant effectuée en fonction : - du nombre B d’unité de virtualisation de sauvegarde défini dans ledit schéma de protection ; - d’une comparaison entre une charge de service totale atteinte SL et une charge de service maximale P L max autorisée par unité de virtualisation (UV) dudit ensemble ( set ). Produit programme d’ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu’il comprend des instructions de code de programme pour l’exécution d'un procédé selon l'une quelconque des revendications 1 à 10, lorsqu’il est exécuté par un ordinateur.