EP4728375A1

EP4728375A1 - Système de clonage multi-clusters

Info

Publication number: EP4728375A1
Application number: EP24731600.3A
Authority: EP
Inventors: Laurent VALEYRE; Gaël FROMENTOUX; Frédéric FIEAU
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2023-06-19
Filing date: 2024-06-10
Publication date: 2026-04-22
Also published as: WO2024260762A1; FR3150022A1

Abstract

Un orchestrateur dans un environnement informatique en nuage, configuré pour : recevoir d'un gestionnaire des instructions de clonage pour désigner (108) des ressources au sein d'un environnement de travail initial, les ressources désignées définissant un déploiement initial d'un service, recevoir du gestionnaire une contrainte associée aux instructions de clonage, recueillir, en temps réel, des informations sur une utilisation de ressources individuelles issues d'une pluralité d'agglomérations de traitement de données, les informations étant obtenues avec une granularité suffisante pour permettre une analyse de l'utilisation de chaque ressource individuelle, et identifier (110), en tenant compte à la fois des instructions de clonage reçues, de la contrainte reçue et des informations recueillies, des ressources cibles dans au moins un nouvel environnement de travail en vue d'un clonage des ressources désignées, permettant ainsi un nouveau déploiement du service respectant la contrainte.

Description

Système de clonage multi-clusters

L'invention 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.

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 approprié pour reconfigurer le routage suite à un changement de topologie qui serait induit par une telle réplication.

Résumé

L’invention vise à améliorer la situation.

Il est ainsi proposé, selon un aspect, un orchestrateur dans un environnement informatique en nuage, configuré pour :
recevoir d’un gestionnaire une instruction de clonage pour désigner une ressource au sein d’une infrastructure de communication initiale, la ressource désignée définissant un déploiement initial d’un service,
recevoir du gestionnaire une contrainte associée à l’instruction de clonage,
recueillir une information sur une utilisation de ressources individuelles issues d’une pluralité d’agglomérations de traitement de données, l’information étant obtenue avec une granularité suffisante pour permettre une analyse de l'utilisation de chaque ressource individuelle, et
identifier, en tenant compte à la fois de l’instruction de clonage reçue, de la contrainte reçue et de l’information recueillie, une ressource cible dans au moins une nouvelle infrastructure de communication en vue d’un clonage de la ressource désignée, permettant ainsi un nouveau déploiement du service respectant la contrainte.

De par sa configuration, l’orchestrateur permet de gérer de manière efficiente le clonage de services en se basant sur une analyse en temps réel des ressources disponibles, et en tenant compte des instructions de clonage et des contraintes fournies. Cela offre une flexibilité accrue dans le déploiement des services, en permettant un clonage précis et ciblé des ressources nécessaires, optimisant ainsi l'utilisation des ressources et le respect des contraintes associées.

Il est également proposé, selon un autre aspect, un gestionnaire d’au moins un service dans un environnement informatique en nuage, le gestionnaire étant configuré pour :
détecter un événement déclencheur résultant d’une application d’une stratégie de gestion du service,
définir une contrainte associée à l’événement déclencheur,
envoyer, suite à la détection de l’événement déclencheur, une instruction de clonage à un orchestrateur, l’instruction de clonage permettant à l’orchestrateur de désigner une ressource dans une infrastructure de communication initiale, définissant un déploiement initial du service, et
envoyer la contrainte définie à l’orchestrateur, la contrainte permettant à l’orchestrateur d’identifier, dans au moins une nouvelle infrastructure de communication, une ressource cible en vue d’un clonage de la ressource désignée, permettant ainsi un nouveau déploiement du service respectant la contrainte.

Ainsi, le gestionnaire est capable de déclencher un processus de clonage sur la base d'événements spécifiques et d'envoyer des instructions et contraintes de clonage à l'orchestrateur. Cela permet une gestion proactive de services, offrant une réponse rapide et adaptée aux changements dans leur environnement de travail.

Il est également proposé, selon un autre aspect, un système de clonage dans un environnement informatique en nuage, le système comprenant un orchestrateur et un gestionnaire définis par exemple comme ci-dessus. Le système peut comprendre en outre un service virtuel configuré comme un dispositif de routage de manière à rediriger, à l'issue d'une opération de clonage, un trafic d’un déploiement initial d’un service vers le nouveau déploiement du service, et ce, de manière transparente pour l'orchestrateur et le gestionnaire.

Le système de clonage proposé permet une réplication efficace et transparente des services déployés. Le service virtuel de routage en particulier offre une transition sans heurt entre le déploiement d'origine et le nouveau déploiement, minimisant ainsi les interruptions de service. Le service virtuel de routage peut aussi contribuer, dans le cas où la redirection est partielle, à assurer une distribution optimale de requêtes entre les différents déploiements.

Les différents aspects ainsi évoqués participent à une structure générale de commande de clonage et contribuent chacun à une gestion dynamique et optimisée des ressources hébergeant des services dans l’environnement informatique en nuage. En effet, grâce au déclenchement du clonage en fonction des contraintes spécifiques de chaque service, en tenant compte des caractéristiques du service à cloner et des conditions du réseau, et en réalisant une mise à jour dynamique du routage en fonction des changements de topologie, les différents aspects évoqués offrent une capacité d'adaptation et de réactivité face aux variations de la demande et des conditions du réseau. Ainsi, lorsqu'un incident survient sur un service hébergé dans un environnement de travail initial, les aspects ainsi évoqués permettent de déclencher et de mettre en œuvre le clonage de ce service vers un nouvel environnement de travail, tout en tenant compte de contraintes relatives par exemple à la sécurité et/ou à la qualité de service. Ceci permet d'assurer une continuité de service même dans les cas, par exemple, d’une défaillance ou d’une augmentation soudaine de la demande pour le service considéré.

Il est également proposé un procédé d’orchestration de ressources dans un environnement informatique en nuage, le procédé comprenant les étapes suivantes mises en œuvre par un orchestrateur :
recevoir d’un gestionnaire une instruction de clonage pour désigner une ressource au sein d’une infrastructure de communication initiale, la ressource désignée définissant un déploiement initial d’un service,
recevoir du gestionnaire une contrainte associée à l’instruction de clonage,
recueillir une information sur une utilisation de ressources individuelles issues d’une pluralité d’agglomérations de traitement de données, l’information étant obtenue avec une granularité suffisante pour permettre une analyse de l'utilisation de chaque ressource individuelle, et
identifier, en tenant compte à la fois de l’instruction de clonage reçues, de la contrainte reçue et de l’information recueillie, une ressource cible dans au moins une nouvelle infrastructure de communication en vue d’un clonage de la ressource désignée, permettant ainsi un nouveau déploiement du service respectant la contrainte.

Ce procédé d'orchestration de ressources offre une méthode systématique et automatisée pour le clonage des services, qui prend en compte les contraintes de déploiement et l'utilisation des ressources en temps réel. Cela permet une meilleure gestion des ressources et une plus grande efficacité dans le déploiement des services.

Optionnellement, l’information recueillie est issue de proxys intégrés dans les agglomérations de traitement de données et associés à des ressources formant une pluralité d’infrastructures de communication candidates, et la nouvelle infrastructure de communication est choisi parmi la pluralité d’infrastructures de communication candidates.

Ceci contribue ainsi à faciliter l'identification par l'orchestrateur de cibles appropriées pour le clonage des ressources désignées et la création du nouvel environnement de travail pour le nouveau déploiement du service. Cela contribue à une répartition optimale des ressources, améliorant ainsi l'efficacité et la performance du système.

Il est également proposé un procédé de gestion de service dans un environnement informatique en nuage, le procédé comprenant les étapes suivantes mises en œuvre par un gestionnaire :
détecter un événement déclencheur résultant d’une application d’une stratégie de gestion du service,
définir une contrainte associée à l’événement déclencheur,
envoyer, suite à la détection de l’événement déclencheur, une instruction de clonage à un orchestrateur, l’instruction de clonage permettant à l’orchestrateur de désigner une ressource dans une infrastructure de communication initiale, définissant un déploiement initial du service, et
envoyer la contrainte définie à l’orchestrateur, la contrainte permettant à l’orchestrateur d’identifier, dans au moins une nouvelle infrastructure de communication, une ressource cible en vue d’un clonage de la ressource désignée, permettant ainsi un nouveau déploiement du service respectant la contrainte.

Ce procédé de gestion de service offre une méthode proactive pour le clonage et le déploiement de services basée sur la détection d'événements spécifiques. Cela permet une réaction rapide et adaptée aux changements dans l'environnement de travail, améliorant la résilience et la disponibilité des services.

Optionnellement, le procédé comprend en outre l’étape suivante mise en œuvre par le gestionnaire :
recueillir une information fournie par l’orchestrateur sur une utilisation d’un ensemble de ressources incluant, au moins, la ressource définissant le déploiement initial du service, et
dans lequel la détection de l’événement déclencheur est basée sur l’information obtenue.

La collecte en temps réel d'informations sur l'utilisation des ressources par le gestionnaire permet une détection précise des événements déclencheurs. Cela augmente la précision de la gestion des services et la réactivité face aux changements.

Optionnellement, la détection de l’événement déclencheur est relative à une application d’une politique incluant au moins un critère d’optimisation choisi parmi le partage de charge, la résilience, la sécurité, la disponibilité, le coût, l’énergie et/ou l’impact environnemental.

La capacité de détecter un événement déclencheur basé sur une variété de politiques, en particulier sur celles mentionnées ici, offre une flexibilité et une adaptabilité accrues dans la gestion des services.

Optionnellement, les procédés précités comprennent en outre l’étape suivante mise en œuvre par l’orchestrateur ou le gestionnaire :
transmettre une information concernant une modification de topologie suite au clonage à un service virtuel configuré comme un dispositif de routage,
l’information transmise permettant au service virtuel de rediriger, à l'issue du clonage, un trafic du déploiement initial du service vers le nouveau déploiement du service, de manière transparente pour l'orchestrateur et le gestionnaire.

Les informations ainsi transmises par l’orchestrateur ou le gestionnaire permettent une redirection transparente du trafic, qui contribue à améliorer la continuité du service.

Il est également proposé un programme d’ordinateur comprenant des instructions qui, lorsque le programme est mis en œuvre par un processeur, conduisent à mettre en œuvre l’un des procédés précités.

D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :

Fig. 1

illustre un processus de gestion de ressources et de clonage selon un exemple de réalisation.

Fig. 2

représente un état initial d’un système comprenant deux clusters avant la mise en œuvre d’un processus de clonage.

Fig. 3

représente un exemple d’état final du système de après la mise en œuvre d’un processus de clonage, reflétant des changements dans les clusters.

Fig. 4 Fig. 5

et représentent, chacun, un autre exemple d’état final du système de après la mise en œuvre d’un processus de clonage différent, reflétant des changements différents dans les clusters.

Fig. 6 Fig. 7 Fig. 8

, et illustrent schématiquement un processus détaillé de mise à jour d’un routage à l’issue d’un clonage d’un service, à travers différents états successifs des clusters concernés, dans un exemple de réalisation.

Fig. 9

illustre une série d’échanges entre différents éléments pour mettre à jour un routage à l’issue d’une procédure de clonage, selon un exemple de réalisation

Fig. 10

illustre une série d’échanges entre différents éléments pour mettre en œuvre une procédure de clonage, selon un exemple de réalisation.

La présente divulgation concerne un système de clonage qui opère dans un environnement informatique en nuage, spécifiquement dans les systèmes de télécommunications. Ce système de clonage fournit un moyen de répliquer des configurations supportant des services déployés.

Dans ce document, le terme « service » est utilisé 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.

Il est important de noter que le système de clonage décrit ici concerne la duplication et le transfert à la fois de « contenu » et de « contenant ». D'un côté, en ce qui concerne le « contenu », le système de clonage peut être configuré pour copier un logiciel, une application, un service ou un microservice en cours d'exécution dans une ressource initiale. Par exemple, des microservices spécifiques ou des configurations de points d’accès (en anglais « Point of Delivery ») peuvent ainsi être clonés d'un environnement de travail initial à un nouvel environnement de travail. D'un autre côté, en ce qui concerne le « contenant », le système de clonage peut être configuré pour préparer une infrastructure de communication cible pour recevoir le contenu cloné. Par exemple, afin de cloner une ressource d'un emplacement à un autre, l'infrastructure nécessaire en matière de traitement et de stockage de données peut être reproduite pour accueillir le contenu cloné.

L’expression « infrastructure de communication », tel qu'utilisée dans ce document, se réfère au support physique et logiciel qui permet la communication et le partage de ressources et de services. Cette infrastructure peut comprendre 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. Elle 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.

Le système de clonage peut être configuré pour gérer efficacement ces deux aspects du clonage - à la fois du contenu et du contenant - ce qui le rend particulièrement pertinent pour les opérateurs et entreprises qui cherchent à améliorer l'efficacité et la sécurité de leurs applications dans les environnements de conteneurs et de micro-services.

Le système de clonage comprend notamment un orchestrateur et un gestionnaire.

L’orchestrateur, dans l’environnement informatique en nuage, est conçu pour recevoir du gestionnaire une ou plusieurs instructions de clonage, éventuellement sérialisées. L’interprétation de cette ou de ces 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 outre, l'orchestrateur reçoit du gestionnaire une contrainte associée à cette ou ces instructions de clonage.

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.

La collecte d’informations sur l'utilisation des ressources dans l'infrastructure de communication peut se faire de diverses manières, dépendamment de la spécificité du contexte. Elle peut être effectuée en temps réel, ce qui signifie que l'information est collectée et analysée au fur et à mesure qu'elle est générée. Cette méthode permet une réaction rapide à des changements dans l'utilisation des ressources et peut être utile pour la gestion des ressources en temps réel. Alternativement, une approche dynamique de la collecte d'informations peut être adoptée. Dans ce contexte, la dynamique se réfère à la capacité de s'adapter à des changements dans le système de clonage ou l'infrastructure de communication, en modifiant la fréquence ou le type d'informations collectées en fonction des circonstances. Par exemple, l'orchestrateur peut être configuré pour collecter plus fréquemment des informations lorsqu'une augmentation de l'utilisation des ressources est détectée, ou pour collecter des types d'informations spécifiques en réponse à certains événements ou conditions. Enfin, la collecte d'informations peut aussi se faire en réponse à une notification. Dans ce cas, l'orchestrateur est configuré pour collecter des informations lorsque certaines conditions sont remplies, ou lorsque certaines notifications sont reçues. Par exemple, une notification peut être émise lorsque l'utilisation d'une ressource atteint un certain seuil, déclenchant la collecte d'informations par l'orchestrateur. Ces méthodes de collecte d'informations ne sont pas mutuellement exclusives et peuvent être utilisées conjointement.

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 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 contrainte spécifiée.

Le gestionnaire joue un rôle clé dans le déclenchement du processus de clonage. Il est capable de détecter un événement déclencheur résultant de l'application d'une stratégie de gestion du service. Une telle stratégie de gestion peut viser à optimiser ou co-optimiser différents critères tels que le partage de charge, la résilience, la sécurité, la gestion du coût, de l'énergie, de l’impact environnemental, etc. Suite à la détection de cet événement, le gestionnaire définit une contrainte associée à l'événement et envoie des instructions de clonage à l'orchestrateur.

Ces instructions permettent à l'orchestrateur de désigner des ressources dans l'environnement de travail initial, définissant ainsi un déploiement initial du service. Le gestionnaire envoie également la contrainte définie à l'orchestrateur, ce qui permet à ce dernier d'identifier, dans au moins un nouvel environnement de travail, des ressources cibles pour le clonage.

Le système de clonage peut comprendre également un service virtuel configuré comme un dispositif de routage. A l'issue d'une opération de clonage, ce service redirige le trafic d'un déploiement initial d'un service vers un nouveau déploiement du service, 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.

En résumé, le système de clonage proposé offre une solution efficace pour répliquer les configurations nécessaires aux services et applications déployés dans un environnement informatique en nuage distribué. Il permet une gestion fine et coordonnée des ressources, une réponse agile à des événements déclencheurs et une transition transparente vers de nouveaux déploiements de services et d'applications. Il répond aux défis de répartition des ressources, de reconfiguration et de redondance.

Dans la gestion des ressources cloud, la répartition des services, des applications et des données sur différents environnements informatiques est un défi majeur, en particulier lorsque ces ressources proviennent de différents fournisseurs. Jusqu'à présent, l'absence d'un système de clonage adapté compliquait les opérations de distribution des ressources, de reconfiguration et de redondance. Le système de clonage proposé résout ce problème technique en offrant une solution efficace pour configurer les services et applications déployés dans un environnement distribué.

En plus de faciliter la réplication des configurations, le système de clonage répond également à d'autres besoins importants. Il offre un accès simplifié et sécurisé aux fonctions et micro-services, permettant ainsi la réplication de la logique d'accès aux données et la gestion de la sécurité associée. Cela se révèle extrêmement bénéfique pour les opérateurs et les entreprises cherchant à améliorer l'efficacité et la sécurité de leurs applications et services dans des environnements de conteneurs et de micro-services.

Le système de clonage 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 d’un service donné à cloner – 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 – le système de clonage est conçu pour s'adapter à ces différents contextes.

Avant d'aller plus loin dans la description de l'invention, il est important de clarifier quelques termes spécifiques aux environnements informatiques en nuage.

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. 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 service mesh open source, couramment utilisé, qui fournit une manière uniforme de connecter, gérer et sécuriser des microservices à l’aide de proxys sidecar.

À présent, nous allons décrire un mode particulier de réalisation du système de clonage dans le contexte 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 plateforme de gestion de conteneurs. Indépendamment de la plateforme utilisée, les opérations mises en œuvre par le système de clonage permettent de faciliter la gestion et la coordination des ressources entre différents environnements informatiques.

Dans la description qui va suivre, des chiffres de référence identiques désignent des éléments identiques ou ayant des fonctions similaires.

Dans le contexte du processus de clonage décrit ici, il est important de souligner que 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 télécom. 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.

La 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.

Au bloc (110), des ressources de destination sont identifiées. 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.

Au bloc (112), le clonage est effectué et au bloc (114), les informations de routage du service sont mises à jour. Ces deux dernières tâches 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 (108) à (114) de la . 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 (112) et (114) de la . 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.

La 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, représenté 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.

La représente un état final de l’un des clusters (200) de la à 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).

La représente un autre état final de l’un des clusters (200) de la à 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).

La représente un autre état final des clusters (200, 300) de la à l’issue d’une procédure de clonage d’un pod et 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 premier pod (212) à cloner, ainsi qu’un premier nœud à cloner (210), ce premier pod (212) et ce premier nœud (210) constituant un ensemble de ressources d’origine. On peut supposer ici que l’orchestrateur (202) n’était pas en mesure d’identifier des ressources de destination dans le premier cluster pour une cause en lien avec tout événement interne du premier cluster et/ou pour respecter une contrainte externe. L’orchestrateur (202) a alors plutôt communiqué avec un autre orchestrateur (302) situé dans un second cluster (300) afin d’identifier avec succès, dans le second cluster, un second nœud (330) et un second pod (322) en tant qu’ensemble de ressources 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) et le premier pod (212) dans le second pod (322).

La présente schématiquement le routage d'une requête vers un service spécifique (406) associé à une application donnée (408) dans un environnement de cluster (400) faisant partie d'un environnement mesh basé sur ISTIO. Dans ce cadre, le cluster (400) comprend un proxy sidecar (404) et un espace de noms (402) qui encapsule le service spécifique (406) et l'application donnée (408). Le proxy sidecar (404) sert d'intermédiaire, facilitant le transfert des requêtes entrantes vers le service cible.

Il convient de noter que l'utilisation d'un environnement mesh basé sur ISTIO pour ce processus n'est pas une nécessité, mais plutôt une option préférée en raison de sa capacité à faciliter le routage et le basculement entre différents services et clusters. D'autres environnements mesh pourraient également être utilisés, à condition qu'ils disposent des capacités nécessaires pour effectuer les étapes décrites ci-dessous.

Dans le cadre d'une opération visant à déplacer ce service spécifique (406) vers un autre cluster tout en assurant la continuité de service, plusieurs étapes sont illustrées de la à la .

La illustre une étape intermédiaire de cette opération où le service spécifique (406) est dupliqué dans un nouveau cluster de destination (500). Le cluster de destination (500) comprend également un proxy sidecar (504) et un espace de noms (502) qui contient le clone du service spécifique (506). Un service virtuel (410) est créé dans le cluster d'origine (400) et agit comme un mini-routeur. Deux règles de destination (412, 512), l'une dans le cluster d'origine et l'autre dans le cluster de destination, sont établies et configurées dans le service virtuel (410) avec des poids respectifs de 100% et 0%.

À ce stade, le service virtuel (410) dirige toutes les requêtes entrantes uniquement vers le service d'origine (412) dans le cluster d'origine (400), laissant le nouveau service (512) dans le cluster de destination (500) en attente de recevoir le trafic.

La illustre l'étape finale de la migration du service. À ce stade, les poids définis précédemment dans le service virtuel (410) sont inversés, c'est-à-dire que la règle de destination (412) dans le cluster d'origine a maintenant un poids de 0%, tandis que la règle de destination (512) dans le cluster de destination a un poids de 100%.

Cela signifie que toutes les requêtes entrantes sont désormais acheminées vers le service cloné (506) dans le cluster de destination (500). Ce processus de basculement peut être effectué de manière contrôlée et réversible si nécessaire, garantissant ainsi un niveau élevé de fiabilité et de sécurité.

Enfin, une fois que le service d'origine (406) n'est plus nécessaire, il peut être supprimé en toute sécurité, ainsi que sa règle de destination (412) correspondante, ne laissant que le service cloné (506) dans le cluster de destination (500). Le service virtuel (410) reste opérationnel en tant que mini-routeur, prêt pour de futures opérations de migration de service.

La illustre de manière détaillée les interactions entre un utilisateur final, le service virtuel (410), les règles de destination (412, 512) et les services A (406) et B (506) dans le cadre d'une mise à jour du routage. Les numéros associés à chaque flèche indiquent l'ordre séquentiel des échanges. Les interactions décrites permettent une redirection efficace du trafic entre les différents services, illustrant la flexibilité et le contrôle offerts par l'invention.

Dans le cadre d’un premier échange survenant dans une situation correspondant à la , une requête entrante (602) est initiée par l'utilisateur final et adressée au service virtuel (410) dans le cluster d'origine (400). Le service virtuel, à travers la règle de destination active (412) et selon les poids couramment définis, achemine cette requête (604) puis (606) vers le service d’origine (406) localisé dans le même cluster (400). Le service d’origine (406) répond alors (608) à la requête et envoie cette réponse à l'utilisateur final.

Le changement des poids (610) est ensuite émis par l'utilisateur final vers le service virtuel (410). Cet ajustement est nécessaire pour initier la transition du routage des requêtes du service d’origine (406) vers le service cloné (506).

Un second échange survenant dans une situation correspondant à la met en évidence l'effet de ce changement de poids. Une nouvelle requête entrante (612) de l'utilisateur final est acheminée vers le service virtuel (410). Cette fois, compte tenu des poids réajustés, la requête est redirigée (614) vers la règle de destination (512) dans le cluster de destination (500), qui achemine ensuite la requête (616) vers le service cloné (506). Le service cloné (506) répond (618) à la requête et renvoie cette réponse à l'utilisateur final.

La illustre une série d’échanges entre les plans de contrôle, les nœuds et les proxys sidecar impliqués dans la mise en œuvre d’une procédure de clonage de ressources depuis un nœud d’origine (210) vers un nœud de destination (330), comme illustré sur la , dans un exemple d’implémentation.

Un premier échange illustre l’émission d’une requête initiale (702) de l'orchestrateur (202) situé dans le cluster d’origine (200) vers l'orchestrateur (302) situé dans le cluster de destination (300). Après avoir reçu la requête, l'orchestrateur dans le cluster de destination envoie une confirmation (ACK) de réception (704) à l'orchestrateur dans le cluster d’origine. Ce premier échange déclenche le processus de clonage proprement dit.

Dans un deuxième échange, le nœud d’origine (210) est cloné (706) dans le nœud de destination (330). Ce dernier envoie ensuite une confirmation (ACK) de réussite de clonage (708) au nœud d'origine.

Dans un troisième échange, l'orchestrateur du cluster de destination vérifie le succès du clonage (710) en envoyant une requête à l'orchestrateur du cluster d’origine. En réponse, ce dernier envoie une confirmation (ACK) de la réussite du clonage (712) à l'orchestrateur du cluster de destination.

Enfin, un message de test (714) est envoyé depuis un proxy sidecar situé dans un pod du nœud d'origine (210) vers un proxy sidecar situé dans un pod du nœud cloné (330). Ceci indique que le processus de clonage s'est terminé avec succès et que les deux pods concernés peuvent maintenant communiquer.

La illustre ainsi une implémentation pratique d’une procédure de clonage dans laquelle un dialogue continu entre les éléments impliqués assure une mise en œuvre précise et contrôlée du clonage.

Bien que la présente invention 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.

En outre, bien que des aspects de l'invention puissent être décrits comme étant un processus, un dispositif, un système, une procédure ou une méthode, il est à noter que l'invention peut également couvrir une mémoire informatique sous forme de support lisible par ordinateur ayant des instructions de programme codées, qui, lorsqu'elles sont exécutées par un ordinateur, permettent de réaliser les processus, dispositifs, systèmes, procédures ou méthodes décrits dans ce document.

Claims

Orchestrateur (202, 302) dans un environnement informatique en nuage, configuré pour :
recevoir d’un gestionnaire une instruction de clonage pour désigner (108) une ressource (210, 212, 220, 406) au sein d’une infrastructure de communication initiale, la ressource désignée définissant un déploiement initial d’un service,
recevoir du gestionnaire une contrainte associée à l’instruction de clonage,
recueillir une information sur une utilisation de ressources individuelles issues d’une pluralité d’agglomérations de traitement de données (200, 300, 400, 500), l’information étant obtenue avec une granularité suffisante pour permettre une analyse de l'utilisation de chaque ressource individuelle, et
identifier (110), en tenant compte à la fois de l’instruction de clonage reçue, de la contrainte reçue et de l’information recueillie, une ressource cible (222, 230, 322, 330, 506) dans au moins une nouvelle infrastructure de communication en vue d’un clonage de la ressource désignée, permettant ainsi un nouveau déploiement du service respectant la contrainte.
Gestionnaire d’au moins un service dans un environnement informatique en nuage, le gestionnaire étant configuré pour :
détecter un événement déclencheur résultant d’une application d’une stratégie de gestion du service,
définir une contrainte associée à l’événement déclencheur,
envoyer, suite à la détection de l’événement déclencheur, une instruction de clonage à un orchestrateur (202, 302), l’instruction de clonage permettant à l’orchestrateur de désigner (108) une ressource (210, 212, 220, 406) dans une infrastructure de communication initiale, définissant un déploiement initial du service, et
envoyer la contrainte définie à l’orchestrateur, la contrainte permettant à l’orchestrateur d’identifier (110), dans au moins une nouvelle infrastructure de communication, une ressource cible (222, 230, 322, 330, 506) en vue d’un clonage de la ressource désignée, permettant ainsi un nouveau déploiement du service respectant la contrainte.
Système de clonage dans un environnement informatique en nuage, le système comprenant un orchestrateur (202, 302) selon la revendication 1 et un gestionnaire selon la revendication 2.
Système de clonage selon la revendication 3, comprenant en outre un service virtuel (410) configuré comme un dispositif de routage de manière à rediriger, à l'issue d'une opération de clonage, un trafic du déploiement initial d’un service (406) vers le nouveau déploiement du service (506), et ce, de manière transparente pour l'orchestrateur et le gestionnaire.
Procédé d’orchestration de ressources dans un environnement informatique en nuage, le procédé comprenant les étapes suivantes mises en œuvre par un orchestrateur (202, 302) :
recevoir d’un gestionnaire une instruction de clonage (108) pour désigner une ressource (210, 212, 220, 406) au sein d’une infrastructure de communication initiale, la ressource désignée définissant un déploiement initial d’un service,
recevoir du gestionnaire une contrainte associée à l’instruction de clonage,
recueillir une information sur une utilisation de ressources individuelles issues d’une pluralité d’agglomérations de traitement de données (200, 300, 400, 500), l’information étant obtenue avec une granularité suffisante pour permettre une analyse de l'utilisation de chaque ressource individuelle, et
identifier (110), en tenant compte à la fois de l’instruction de clonage reçue, de la contrainte reçue et de l’information recueillie, une ressource cible (222, 230, 322, 330, 506) dans au moins une nouvelle infrastructure de communication en vue d’un clonage de la ressource désignée, permettant ainsi un nouveau déploiement du service respectant la contrainte.
Procédé selon la revendication 5, dans lequel l’information recueillie est issue de proxys (404, 504) intégrés dans les agglomérations de traitement de données et associés à des ressources formant une pluralité d’infrastructures de communication candidates, et la nouvelle infrastructure de communication est choisie parmi la pluralité d’infrastructures de communication candidates.
Procédé de gestion de service dans un environnement informatique en nuage, le procédé comprenant les étapes suivantes mises en œuvre par un gestionnaire :
détecter un événement déclencheur résultant d’une application d’une stratégie de gestion du service,
définir une contrainte associée à l’événement déclencheur,
envoyer, suite à la détection de l’événement déclencheur, une instruction de clonage à un orchestrateur (202, 302), l’instruction de clonage permettant à l’orchestrateur de désigner (108) une ressource (210, 212, 220, 406) dans une infrastructure de communication initiale, définissant un déploiement initial du service, et
envoyer la contrainte définie à l’orchestrateur, la contrainte permettant à l’orchestrateur d’identifier (110), dans au moins une nouvelle infrastructure de communication, une ressource cible (222, 230, 322, 330, 506) en vue d’un clonage de la ressource désignée, permettant ainsi un nouveau déploiement du service respectant la contrainte.
Procédé selon la revendication 7, comprenant en outre l’étape suivante mise en œuvre par le gestionnaire :
recueillir une information fournie par l’orchestrateur (202, 302) sur une utilisation d’un ensemble de ressources incluant, au moins, la ressource définissant le déploiement initial du service, et
dans lequel la détection de l’événement déclencheur est basée sur l’information obtenue.
Procédé selon la revendication 7 ou 8, dans lequel la détection de l’événement déclencheur est relative à une application d’une politique incluant au moins un critère d’optimisation choisi parmi le partage de charge, la résilience, la sécurité, la disponibilité, le coût, l’énergie et/ou l’impact environnemental.
Procédé selon l’une des revendications 5 à 9, comprenant en outre l’étape suivante mise en œuvre par l’orchestrateur (202, 302) ou le gestionnaire :
transmettre une information concernant une modification de topologie suite au clonage à un service virtuel (410) configuré comme un dispositif de routage,
l’information transmise permettant au service virtuel de rediriger, à l'issue du clonage, un trafic du déploiement initial du service vers le nouveau déploiement du service (506), de manière transparente pour l'orchestrateur et le gestionnaire.
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 l’une des revendications 5 à 10.