PROCÉDÉ DE CONTRÔLE D'UNE GRAPPE DE NOEUDS ESCLAVE PAR UNE GRAPPE DE NOEUDS MAÎTRE,

DISPOSITIFS ET PROGRAMMES D'ORDINATEURS CORRESPONDANTS

Domaine de l'invention

Le domaine de l'invention est celui de l'informatique en nuage ou « cloud computing ».

Plus précisément, l’invention concerne une solution permettant l'orchestration d'une pluralité de grappes de noeuds devant exécuter des tâches identiques de manière identique bien que ces différentes grappes de noeuds ne soient pas co-localisées.

Art antérieur et ses inconvénients

Depuis plusieurs années, les réseaux de télécommunication utilisent des fonctions virtualisées hébergées dans des serveurs, ou noeuds, regroupés en grappes, ou « clusters », donnant naissance à l'informatique en nuage.

Une solution d'orchestration de ces grappes de noeuds est connue sous l'appellation Kubernetes. La [Fig. 1] présente de manière simplifiée l'architecture d'une grappe de noeuds 1 conforme à la solution Kubernetes. La grappe de noeuds 1 comprend un premier nœud 10 dit nœud de gestion, ou « Kubernetes master », et N nœuds de calcul, ou « Kubernetes node », 11·,, i e {1, ... , N), N étant un entier naturel.

Le nœud de gestion 10 comprend un contrôleur 101, un module API (Application Progra ing interface ou interface de programmation d'applications) 102 et une base de données 103 dite ETCD qui consiste en un registre dynamique de configuration des nœuds de calculs 11,.

Un nœud de calcul 11, comprend M conteneurs ou « pods » 110 _j , j e {1, ... , M), M étant un entier naturel. Chaque conteneur 110 _j est doté de ressources permettant l'exécution d'une ou de plusieurs tâches. Une tâche lorsqu'elle est exécutée contribue à la mise en œuvre d'un service ou d'une fonction réseau, telle qu'une fonction DHCP (Dynamic Host Configuration Protocol ou protocole de configuration dynamique des hôtes) par exemple.

Dans un souci de réduction des coûts et d'amélioration de la flexibilité des infrastructures réseaux, les architectures d'informatique en nuage sont le plus souvent des architectures multi- sites dans lesquelles les nœuds constitutifs des grappes de nœuds peuvent être non co-localisés. Par exemple un nœud de gestion 10 et deux nœuds de calcul lli, II2 d'une grappe de nœuds 1 sont situés sur un site A alors que trois autres nœuds de calculs II3, II4, Ils sont quant à eux situés sur un site B distant.

Dans un tel cas de figure, il est nécessaire de synchroniser les états de fonctionnements des différentes tâches exécutées par les nœuds de calculs 11, d'une même grappe de nœuds 1 pour s'assurer de la bonne fourniture du service requis ou de la bonne exécution de la fonction réseau.

Ceci est particulièrement important dans le cas où un partie d'une grappe de nœuds 1 est déployée à la fois dans des sites au sol et dans des satellites en orbite autour de la Terre. En effet, l'ensemble des conteneurs 110 _j de la grappe de nœuds 1 déployés doit être supervisé et orchestré en permanence.

Or, il est difficile de déployer un unique nœud de gestion 10 réparti à la fois dans la partie terrestre et dans la partie satellitaire de la grappe de nœuds 1 car une latence trop importante ne permet pas un niveau de synchronisation satisfaisant entre la partie de la base de données 103 située au sol et la partie de la base de données 103 située dans le satellite.

Il est également difficile d'orchestrer les conteneurs 110 _j embarqués dans un satellite via un nœud de gestion 10 situé au sol car le satellite n'est pas en permanence à portée du nœud de gestion 10.

Afin de résoudre cette problématique, une première solution consiste à déployer une première grappe de nœuds au sol et une deuxième grappe de nœuds dans un ou plusieurs satellites en orbite. Les satellites étant en déplacement continu autour de la Terre, la grappe de nœuds embarquée dans les satellites modifie sa configuration afin de s'adapter à l'ensemble des besoins et des contraintes formulées par les différents opérateurs gérant des réseaux de télécommunication des différents pays survolés. Ces opérations de reconfiguration, comme le déploiement d'un autre système d'exploitation, l'installation de dépendances, le déploiement puis la mise à jour des nœuds de gestion et de calcul, sont chronophages. En effet, il faut compter environ une dizaine de minutes pour un déploiement complet de ce type, ce qui occupe une très grande partie de la période de couverture d'un pays par le satellite.

Une deuxième solution consiste à déployer plusieurs nœuds de gestion 10 pour une même grappe de nœuds 1 au sol et dans un ou plusieurs satellites. Cependant une telle architecture induit un temps de latence pour la synchronisation des bases de données 103 embarquées dans chacun des nœuds de gestion 10. En effet, ces bases de données 103 fonctionnent entre elles au moyen d'un algorithme de consensus, nommé RAFT. Cet algorithme repose sur l'utilisation de temporisations qui sont sensibles à la latence introduite entre chaque opération de réplication du contenu d'une base de données 103. Or, les base de données 103 sont très régulièrement mises à jour afin de maintenir à jour l'état de fonctionnement d'une grappe de nœuds 1.

Ainsi, la répartition des nœuds de gestion 10 entre le sol et les satellites a pour conséquence un allongement de la réactivité des nœuds de gestions de la grappe de nœuds 1 ce qui introduit des ruptures de services.

Il existe donc un besoin d’une solution de déploiement de grappes de nœuds ne présentant pas tout ou partie des inconvénients précités.

Exposé de l’invention

L’invention répond à ce besoin en proposant un procédé de contrôle d'une première grappe de nœuds, dite grappe esclave, par une deuxième grappe de nœuds, dite grappe maître, une grappe de nœuds comprenant au moins un nœud de calcul exécutant au moins une tâche, ledit procédé de contrôle étant mis en œuvre par ladite grappe maître et comprenant les étapes suivantes :

- réception d'une demande de prise de contrôle de ladite grappe esclave identifiant au moins une tâche destinée à être exécutée par au moins un nœud de calcul de ladite grappe esclave,

- création d'un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,

- transmission dudit fichier de configuration à destination de ladite grappe esclave,

- réception d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise. Une telle solution permet de déployer une solution d'informatique en nuage dans laquelle les grappes de noeuds constitutives de l'architecture déployée ne sont pas co-localisées mais ne présentant pas les inconvénients de l'état de l'art précédemment cités.

Ceci est rendu possible en établissant une relation maître-esclave entre une première grappe de noeuds et une deuxième grappe de noeuds.

Une telle solution permet de s'affranchir des problèmes liés à la synchronisation des bases de données des noeuds de gestion des grappes de noeuds puisque dans une telle solution, seule la synchronisation de la base de données du nœud de gestion de la grappe de nœuds maître importe. En effet, dans la présente solution, une fois que la grappe de nœuds esclave a été configurée au moyen du ficher de configuration, les bases de données des nœuds de gestion des grappes de nœuds esclaves n'ont pas besoin d'être synchronisées avec la base de données du nœud de gestion de la grappe de nœuds maître. Cela est possible car les conditions d'exécutions spécifiées dans le fichier de configuration correspondent aux conditions d'exécution courantes appliquées par les nœuds de la grappe maître.

Ainsi, bien que d'un point de vue matériel les deux grappes de nœuds, maître et esclave, soient des grappes de nœuds indépendantes, elles se comportent d'un point de vue fonctionnel comme une seule et même grappe de nœuds. La grappe maître et la grappe esclave sont liées et possèdent un comportement identique permettant une bonne exécution des services requis ou des fonctions réseaux.

Les conditions d'exécution des tâches par la grappe maître et la grappe esclave sont identiques car ces deux grappes faisant partie d'une même architecture d'informatique en nuage, il est important d'assurer une exécution cohérente des fonctions réseau entre les différents composant de l'architecture d'informatique en nuage sachant que, pour un service donné ou une fonction réseau donnée, certaines tâches liées à la fourniture de ce service ou de cette fonction seront exécutées en partie dans la grappe maître et en partie dans la grappe esclave.

Ainsi, une condition d'exécution peut être un minimum de capacité mémoire requise pour l'exécution de la tâche. Tant que la condition d'exécution est respectée par la grappe maître et la grappe esclave, la capacité mémoire effective de la grappe maître et de la grappe esclave peuvent être différentes. Ainsi, si la condition d'exécution est minimum de capacité mémoire requise = 2Goctets de mémoire et que la grappe maître affiche une capacité mémoire de 6Go et que la grappe esclave affiche une capacité mémoire de 4Go alors la condition d'exécution est respectée puisque de manière identique les deux grappes maître et esclave respecte une condition d'exécution identique à savoir afficher un minimum de capacité mémoire de 2Go.

Dans la solution objet de l'invention, il suffit de configurer une première grappe de nœuds, située par exemple au sol, et lui demander de prendre le contrôle d'une deuxième grappe de nœuds, par exemple située dans un ou plusieurs satellites, ou dans tout autre véhicule d’une flotte. Lorsque la première grappe peut communiquer avec la deuxième grappe, elle en prend le contrôle et lui transfère un fichier de configuration permettant à la deuxième grappe d'exécuter les tâches requises.

Selon une première implémentation du procédé de contrôle d'une grappe de nœuds esclave, les tâches exécutées par la grappe maître étant réparties en une pluralité de groupes de tâches, un groupe de tâches comprenant au moins une tâche, le fichier de configuration comprend un identifiant d'au moins un groupe de tâches et les conditions d'exécution attendues relatives dudit groupe de tâches.

Il est intéressant de répartir les différentes tâches à exécuter en groupes. De tels groupes peuvent par exemple comprendre l'ensemble des tâches à exécuter pour livrer un service ou exécuter une fonction réseau. D'autres groupes peuvent comprendre des tâches de même nature, les tâches peuvent être également regrouper en fonction du types de ressources qu'elles requièrent pour leur exécution.

Chaque groupe est ensuite doté d'un identifiant et d'un ou plusieurs jeux de conditions d'exécution.

Ainsi, seuls certains groupes de tâches peuvent être exécutés par les noeuds de calculs de la grappe esclave tandis que d'autres sont exécutés uniquement par les noeuds de calculs de la grappe maître. Un même groupe de tâches peut être exécuté à la fois par les noeuds de calculs de la grappe maître et les noeuds de calculs de la grappe esclave.

Dans un mode de réalisation particulier du procédé de contrôle, celui-ci comprend en outre les étapes suivantes :

- réception d'une demande de modification de la configuration de ladite grappe maître comprenant des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe maître,

- configuration de ladite grappe maître au moyen desdites conditions d'exécution attendues, lesdites conditions d'exécution attendues devenant, à l'issue de ladite étape de configuration, les nouvelles conditions d'exécution courantes de ladite tâche,

- création d'un fichier de mise à jour de la configuration de ladite grappe esclave comprenant les conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux nouvelles conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,

- transmission dudit fichier de mise à jour de la configuration à destination de ladite grappe esclave.

Ainsi, chaque mise à jour de la configuration de la grappe maître est dynamiquement déployée sur la grappe esclave assurant ainsi que la grappe maître et la grappe esclave ont toujours un comportement identique.

Lorsque la mise à jour de la configuration de la grappe esclave échoue, le procédé comprend en outre une étape de réception d'un message indiquant l'échec de la mise à jour de la configuration par la grappe esclave.

Ainsi la grappe maître peut chercher à prendre le contrôle d'une autre grappe esclave afin de pouvoir fournir les services ou les fonctions réseaux requis.

Lorsque la mise à jour de la configuration de la grappe esclave échoue, le procédé de contrôle comprend en outre, dans une implémentation particulière, une étape de réception d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la mise à jour de la configuration d'au moins une autre grappe esclave à destination de laquelle la grappe esclave a transmis un fichier de configuration comprenant des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite autre grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître. Dans cette implémentation particulière, la première grappe esclave étant dans l'incapacité de mettre en œuvre la configuration demandée par la grappe maître, elle prend le contrôle d'une deuxième grappe esclave. Pour cela la grappe esclave se comporte comme la grappe maître en transmettant un fichier de configuration comprenant une demande de prise de contrôle à destination de la deuxième grappe esclave.

La grappe maître est informée de cette situation.

Lorsque les grappes maître et esclave ne peuvent communiquer directement, un équipement intermédiaire sert de relai. Dans un tel cas de figure, le procédé comprend une étape de réception d'un message émis par l'équipement intermédiaire indiquant l'impossibilité de transmettre un fichier de configuration à ladite grappe esclave.

Ainsi la grappe maître peut chercher à prendre le contrôle d'une autre grappe esclave afin de pouvoir fournir les services ou les fonctions réseaux requis via l'équipement intermédiaire ou non.

Dans une autre implémentation du procédé de contrôle, ce dernier comprend :

- une étape de réception d'un message d'erreur émis par la grappe esclave,

- une étape de création d'un fichier de réparation de ladite grappe esclave comprenant des paramètres de réparation de ladite grappe esclave,

- transmission dudit fichier de réparation à destination de ladite grappe esclave.

Lorsque la grappe maître est informée de la survenue d'une erreur au niveau de la grappe esclave, elle tente de procéder à une réparation afin d'assurer une continuité de service.

Enfin, le procédé de contrôle peut également comprendre dans certains modes de réalisation :

- une étape de réception d'une demande d'affranchissement de ladite grappe esclave,

- une étape de création d'un fichier de configuration de ladite grappe esclave comprenant des paramètres d'affranchissement de ladite grappe esclave,

- une étape de transmission dudit fichier de configuration à destination de ladite grappe esclave.

Ainsi lorsque les circonstances l'exigent, la grappe esclave retrouve son indépendance et peut être utilisée de manière autonome, c'est-à-dire sans maître, ou bien sous le contrôle d'un nouveau maître, etc.

L'invention a également pour objet un procédé de configuration d'une première grappe de nœuds, dite grappe esclave, par une deuxième grappe de nœuds, dite grappe maître, une grappe de nœuds comprenant au moins un nœud de calcul exécutant au moins une tâche, ledit procédé de configuration étant mis en œuvre par ladite grappe esclave et comprenant les étapes suivantes :

- réception d'un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques à des conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,

- vérification d'une disponibilité des ressources requises pour l'exécution de ladite tâche,

- lorsque les ressources requises sont disponibles, configuration de ladite grappe esclave au moyen dudit fichier de configuration,

- transmission, à destination de la grappe maître, d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise. Si elle n'est pas capable de fournir les ressources requises par la grappe maître, la grappe esclave en informe cette dernière qui peut alors chercher à prendre le contrôle d'une nouvelle grappe esclave.

Selon une implémentation particulière, le procédé de configuration comprend en outre les étapes suivantes :

- réception d'un fichier de mise à jour de la configuration de ladite grappe esclave comprenant des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques à des nouvelles conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,

- vérification d'une disponibilité des ressources requises pour l'exécution de ladite tâche,

- lorsque les ressources requises sont disponibles, mise à jour de la configuration de ladite grappe esclave au moyen dudit fichier de mise à jour de la configuration,

- transmission, à destination de la grappe maître, d'un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise.

Ainsi lorsque les ressources requises sont disponibles, la configuration de la grappe esclave est mise à jour dynamiquement et fonctionne toujours de manière identique à la grappe maître.

Lorsque les ressources requises ne sont pas disponibles, le procédé de configuration comprend en outre une étape d'émission d'un message indiquant l'échec de la mise à jour de la configuration à destination de la grappe maître.

Ainsi la grappe maître peut chercher à prendre le contrôle d'une autre grappe esclave afin de pouvoir fournir les services ou les fonctions réseaux requis.

Le procédé de configuration comprend en outre lorsque les ressources requise ne sont pas disponibles :

- une étape de transmission d'un fichier de configuration comprenant des conditions d'exécution attendues de ladite tâche par au moins un nœud de calcul d'une autre grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,

- une étape de réception d'un message comprenant des informations relatives à la mise en œuvre, par ladite autre grappe esclave, de la configuration requise,

- une étape de transmission, à destination de la grappe maître, d'un message comprenant des informations relatives à la mise en œuvre, par ladite autre grappe esclave, de la configuration requise.

Dans cette implémentation particulière, la première grappe esclave étant dans l'incapacité de mettre en œuvre la configuration demandée par la grappe maître, elle prend le contrôle d'une deuxième grappe esclave. Pour cela la grappe esclave se comporte comme la grappe maître en transmettant un fichier de configuration comprenant une demande de prise de contrôle à destination de la deuxième grappe esclave.

La grappe maître est informée de cette situation.

L'invention à également pour objet un nœud de gestion d'une première grappe de nœuds, dite grappe maître, capable de contrôler une deuxième grappe de nœuds, dite grappe esclave, une grappe de nœuds comprenant également au moins un nœud de calcul exécutant au moins une tâche, ledit nœud de gestion de la grappe maître comprenant des moyens pour : - recevoir une demande de prise de contrôle de ladite grappe esclave identifiant au moins une tâche destinée à être exécutée par au moins un nœud de calcul de ladite grappe esclave,

- créer un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques aux conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,

- transmettre le fichier de configuration à destination de ladite grappe esclave,

- recevoir un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise.

L'invention concerne encore un nœud de gestion d'une première grappe de nœuds, dite grappe esclave, capable de configurer ladite grappe esclave, une grappe de nœuds comprenant également au moins un nœud de calcul exécutant au moins une tâche, ledit nœud de gestion de la grappe esclave comprenant des moyens pour :

- recevoir, depuis une deuxième grappe de nœuds, dite grappe maître, un fichier de configuration de ladite grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par ledit au moins un nœud de calcul de ladite grappe esclave, lesdites conditions d'exécution attendues de ladite tâche étant identiques à des conditions d'exécution courantes de ladite tâche par au moins un nœud de calcul de ladite grappe maître,

- vérifier une disponibilité des ressources requises pour l'exécution de ladite tâche,

- lorsque les ressources requises sont disponibles, configurer ladite grappe esclave au moyen dudit fichier de configuration,

- transmettre, à destination de la grappe maître, un message comprenant des informations relatives à la mise en œuvre, par la grappe esclave, de la configuration requise.

L'invention a enfin pour objets des produits programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre des procédés tels que décrits précédemment, lorsqu'ils sont exécutés par un processeur.

L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel sont enregistrés des programmes d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes des procédés selon l'invention tels que décrits ci-dessus.

Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker les programmes. 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 les programmes d'ordinateur qu'il contient sont exécutables à distance. Les programmes selon l’invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet.

Alternativement, le support d’enregistrement peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution des procédés objets de l'invention précités.

Liste des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :

[fig. 1] : cette figure représente de manière simplifiée l'architecture d'une grappe de noeuds conforme à l'art antérieur,

[fig. 2] : cette figure représente de manière simplifiée l'architecture d'une grappe de noeuds conforme à la solution objet de la présente invention,

[fig. 3] : cette figure représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une grappe esclave,

[fig. 4] : cette figure représente les étapes d'une boucle d'orchestration d'une grappe de noeuds,

[fig. 5] : cette figure représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où, la première grappe esclave étant déjà contrôlée par la grappe maître, la configuration de la grappe maître est mise à jour,

[fig. 6] : cette figure représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où, la première grappe esclave étant déjà contrôlée par la grappe maître, la grappe esclave détecte une erreur,

[fig. 7] : cette figure représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où, les messages échangés entre la grappe maître et la première grappe esclave sont relayés par un équipement intermédiaire,

[fig. 8] : cette figure représente nœud de gestion apte à mettre en œuvre les différents procédés objets de la présente invention.

Description détaillée de modes de réalisation de l'invention

Le principe général de l'invention repose sur l'établissement d'une relation maître-esclave entre deux grappes de nœuds pouvant ou non être co-localisées. L'établissement de cette relation maître-esclave permet, particulièrement lorsqu'une première grappe de nœuds est localisée au sol et une deuxième grappe de nœuds est localisée dans un satellite en orbite autour de la Terre, de s'affranchir des problèmes de synchronisation des bases de données présentes dans les nœuds de gestion des grappes de nœuds entre elles tout en s'assurant que les deux grappes de nœuds ont un comportement identique permettant ainsi la bonne fourniture d'un service requis ou d'une fonction réseau requise.

La [fig. 2] présente de manière simplifiée l'architecture d'une grappe de nœuds 1 conforme à la solution objet de la présente invention. Les éléments déjà décrits en référence à la figure 1 conservent les mêmes signes de référence.

La grappe de nœuds 1 comprend un premier nœud 10 dit nœud de gestion, ou « Kubernetes master », et N nœuds de calcul, ou « Kubernetes node », 11,, i e {1, ... , N), N étant un entier naturel.

Le nœud de gestion 10 comprend un contrôleur 101, un module API (Application Programming interface ou interface de programmation d'applications) 102, une base de données 103 dite ETCD qui consiste en un registre dynamique de configuration des noeuds de calculs 11, et au moins un module de synchronisation 104. Un tel module de synchronisation 104 peut être un module de synchronisation maître 104M ou un module de synchronisation esclave 104E selon que le nœud de gestion 10 dans lequel il se situe appartient à une grappe de nœuds maître ou une grappe de nœuds esclave. Un même nœud de gestion 10 peut comprendre à la fois un module de synchronisation maître 104M et un module de synchronisation esclave 104E car la grappe de nœuds à laquelle il appartient peut à la fois être l'esclave d'une première grappe de nœuds et le maître d'une deuxième grappe de nœuds comme cela sera détaillé plus loin.

Un nœud de calcul 11, comprend M conteneurs ou « pods » 110 _j , j e {1, ... , M), M étant un entier naturel. Chaque conteneur 110 _j est doté de ressources permettant l'exécution d'une ou de plusieurs tâches. Une tâche lorsqu'elle est exécutée contribue à la mise en œuvre d'un service ou d'une fonction réseau, telle qu'une fonction DHCP (Dynamic Host Configuration Protocol ou protocole de configuration dynamique des hôtes) par exemple.

La [fig. 3] représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en œuvre par les différents constituants d'une grappe maître et d'une grappe esclave.

Dans une étape El, le module API 102M du nœud de gestion 10M de la grappe maître reçoit une demande de prise de contrôle DI d'une première grappe esclave. Une telle demande comprend un identifiant IdT d'au moins une tâche destinée à être exécutée par au moins un nœud de calcul II,E de la première grappe esclave. La demande de prise de contrôle peut être émise par un équipement d'un réseau de télécommunication géré par le même opérateur en télécommunication gérant la grappe maître.

Un exemple d'une telle demande de prise de contrôle DI est le suivant : apiVersion: apps/vx kind: CreateEsclave spec: esclave:

- name: IDESCLAVE ipEsclave: x.x.x.x deploymentEsclave: IFNOTEXISTCREATE apiVersion: apps/vx kind: DeploymentEsclave metadata: name: NameDeployement labels: app: LabelDeployement spec: replicas: NombreDeReplicat selector: matchLabels: app: LabelDeployement template: metadata: labels: app: LabelDeployement spec: esclave: IDESCLAVE/IPESCLAVE containers:

- nantie: NOMAPPLICATION image: NONCONTENEUR ports:

- containerPort: port resources: limits:

RESSOURCELIMITE requests:

RESSOURCEDEMANDE

Dans une étape E2, cette demande de prise de contrôle DI est transmise à la base de données 103M qui met à jour ses registres avec les informations comprises dans la demande de prise de contrôle DI telle que, en autre, un identifiant IdT d'au moins une tâche à exécuter par au moins un module de calcul II,E de la première grappe esclave, un identifiant de la première grappe esclave et des informations relatives à des conditions d'exécution de la tâche par le nœud de calcul lliE.

Au cours d'une étape E3, une boucle d'orchestration est mise en œuvre par la grappe maître. Une telle boucle d'orchestration est décrite en référence à la [fig. 4],

Une boucle d'orchestration est un processus mis en œuvre dans une grappe de nœuds au cours de laquelle les conditions d'exécution des tâches exécutées par les nœuds de calcul 11, sont mises à jour en fonction : d'informations comprises dans la base de données 103 et d'informations sur les conditions d'exécution courantes des tâches par les nœuds de calcul 11,.

Les informations sur les conditions d'exécution courantes des tâches sont remontées par les nœuds de calcul 11, au contrôleur 101 ou au module API 102. La mise à jour du contenu de la base de données 103 est indépendante de l'exécution d'une boucle d'orchestration.

La demande de prise de contrôle DI pouvant indiquer quelles tâches exécutées par les nœuds de calcul lli de la grappe de nœuds maître sont destinées à être exécutées par les nœuds de calcul 11, de la première grappe de nœuds esclave, la mise en œuvre d'une telle boucle d'orchestration permet de mettre à jour le fonctionnement de la grappe de nœuds maître.

Ainsi, l'exécution d'une boucle d'orchestration permet de passer d'un état de fonctionnement dit courant d'une grappe de nœuds, l'état courant étant défini notamment par les conditions d'exécution courantes des tâches par les nœuds de calcul 11, et le contenu courant des registres de la base de données 103, à un état de fonctionnement dit état attendu qui est défini entre autre par les conditions d'exécutions des tâches précisées dans la demande de prise de contrôle Dl. A l'issue de l'exécution de la boucle d'orchestration, l'état attendu de la grappe de nœuds devient le nouvel état courant.

Une telle boucle d'orchestration bien que décrite comme mise en œuvre au sein d'un nœud de gestion 10M appartenant à une grappe maître est mise en œuvre de manière identique au sein d'un nœud de gestion 10E appartenant à une première grappe esclave.

Ainsi, dans une étape G1 le contrôleur 101 ou le module de synchronisation 104 transmet une première demande d'informations DU à destination du module API 102. Dans une étape G2, le module API 102 transmet la demande d'informations DU à destination de la base de données 103 et à au moins un nœud de calcul 11,.

Au cours d'une étape G3, la base de données 103 et le nœud de calcul 11, transmettent les informations requises au module API 102. Le module API 102 transmet alors ces informations au contrôleur 101 ou au module de synchronisation 104 au cours d'une étape G4.

Dans une étape G5, le contrôleur 101 ou le module de synchronisation 104 transmet une requête RQT en application d'une configuration déterminée au moyen des informations reçues au cours de l'étape G4.

Une fois la boucle d'orchestration mise en œuvre, le module de synchronisation maître 104M crée un fichier de configuration FC et transmet ce dernier à destination du module API 102M dans une étape E4.

Le module API 102M transmet alors, dans une étape E5, le fichier de configuration FC de la première grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par le nœud de calcul II,E, les conditions d'exécution attendues de la tâche étant identiques aux conditions d'exécution courantes de la même tâche par le nœud de calcul lliM.les conditions d'exécution comprises dans le fichier de configuration peuvent être des contraintes pour que les tâche s'exécutent correctement telles de que les ressources physiques comme CPU, GPU, antennes radio requises, mais aussi les ressources maximales autorisées pour une tâche donnée : nombre de CPU maximum, minimum de ressources en mémoire vive requises, etc.

Les tâches exécutées par la grappe maître peuvent être réparties en une pluralité de groupes de tâches, un groupe de tâches comprenant au moins une tâche. Dans une telle situation, le fichier de configuration FC comprend un identifiant d'au moins un groupe de tâches et les conditions d'exécution attendues relatives dudit groupe de tâches.

De tels groupes peuvent par exemple comprendre l'ensemble des tâches à exécuter pour livrer un service ou exécuter une fonction réseau. D'autres groupes peuvent comprendre des tâches de même nature, les tâches peuvent être également regroupées en fonction du type de ressources qu'elles requièrent pour leur exécution.

Chaque groupe est ensuite doté d'un identifiant et d'un ou plusieurs jeux de conditions d'exécution.

Seuls certains groupes de tâches peuvent être exécutés par les nœuds de calculs de la première grappe esclave tandis que d'autres sont exécutés uniquement par les nœuds de calculs de la grappe maître. Un même groupe de tâches peut être exécuté à la fois par les nœuds de calculs de la grappe maître et les nœuds de calculs de la première grappe esclave.

Le module API 102E du nœud de gestion 10E de la première grappe esclave reçoit le fichier de configuration FC au cours d'une étape E6 et le transmet à destination du module de synchronisation esclave 104E.

Au cours d'une étape E7, le module de synchronisation esclave 104E vérifie, auprès d'au moins un nœud de calcul II,E la disponibilité des ressources requises pour l'exécution de la tâche identifiées dans le fichier de configuration FC. Le module de synchronisation esclave 104E transmet le résultat de cette vérification à destination du module API 102E dans une étape E8. Le module API 102E transmet à son tour cette information à la base de données 103Equi met à jour ses registres dans une étape E9.

Si, dans un premier cas, le module de synchronisation esclave 104E a déterminé que les ressources requises sont disponibles, il transmet un message MC, dit message de confirmation, comprenant des informations relatives à la mise en oeuvre, par la grappe esclave, de la configuration requise et donc indiquant la prise de contrôle de la première grappe esclave par la grappe maître au module API 102E qui le transmet à son tour au module API 102M du nœud de gestion 10M de la grappe maître au cours d'une étape E10. Les étapes E8 et E10 peuvent être exécutées simultanément.

Parallèlement à l'exécution de l'étape E10, la première grappe esclave met en œuvre, dans une étape Eli, une boucle d'orchestration telle que décrite en référence à la figure 4 afin de configurer l'ensemble des nœuds de calculs II,E de la première grappe esclave aves les conditions d'exécution comprises dans le fichier de configuration émis par la grappe maître.

A l'issue de cette étape Eli, la première grappe esclave est contrôlée par la grappe maître et présente un fonctionnement identique à celui de la grappe maître. En d'autres mots, à l'issue de l'étape Eli les tâches exécutées par les nœuds de calcul II,E de la première grappe esclave sont exécutées de la même manière, dans les mêmes conditions et avec les mêmes contraintes que lorsqu'elles sont exécutées par les nœuds de calcul II,M de la grappe maître.

Enfin dans une étape E12, le module API 102M du nœud de gestion 10M de la grappe maître transmet le message de confirmation MC au module de synchronisation maître 104M.

Une fois la prise de contrôle de la première grappe esclave effectué, la première grappe esclave transmet à destination du module API 102 de la grappe maître de manière récurrente des données relatives à l'exécution des tâches exécutées par ses nœuds de calcul II,E.

Si, dans un deuxième cas, au cours de l'étape E7, le module de synchronisation esclave 104E a déterminé que les ressources requises ne sont pas disponibles, le module de synchronisation esclave 104E transmet le résultat de cette vérification à destination du module API 102E dans l'étape E8. Le module API 102E transmet à son tour cette information à la base de données 103E qui met à jour ses registres dans l'étape E9.

Lorsque le module de synchronisation esclave 104E a déterminé que les ressources requises ne sont pas disponibles, il transmet alors un message d'échec EC de la prise de contrôle de la première grappe esclave par la grappe maître au module API 102E qui le transmet à son tour au module API 102M du nœud de gestion 10M de la grappe maître au cours de l'étape E10.

Dans un deuxième mode de réalisation lorsqu'au cours de l'étape E7, le module de synchronisation esclave 104E a déterminé que les ressources requises ne sont pas disponibles, le module de synchronisation esclave 104E transmet le résultat de cette vérification à la base de données 103E dans l'étape E8'.

Ce deuxième mode de réalisation ne peut être mis en œuvre que si la grappe maître autorise explicitement la prise de contrôle d'une deuxième grappe esclave par la première grappe esclave. Une telle autorisation est comprise dans le fichier de configuration FC transmis au cours de l'étape E5.

Dans une étape E9', la base de données 103E met à jour ses registres avec les résultats de la vérification. Au cours d'une étape E10', une boucle d'orchestration est mise en oeuvre par la première grappe esclave afin d'instancier un module de synchronisation maître 104M dans le nœud de gestion 10E de la première grappe esclave

Une fois la boucle d'orchestration mise en œuvre, le module de synchronisation maître 104M du nœud de gestion 10E de la première grappe esclave est instancié et transmet une demande de prise de contrôle D3 d'une deuxième grappe esclave à destination du module API 102E dans une étape E1 . La demande de prise de contrôle D3 comprend un fichier de configuration FC2 d'une deuxième grappe esclave créé par le module de synchronisation maître 104M.

Dans une autre implémentation dans laquelle le nœud de gestion 10E de la première grappe esclave comprend déjà un module de synchronisation maître 104M, le module de synchronisation maître 104M du nœud de gestion 10E transmet, directement après l'étape E7, une demande de prise de contrôle D3 de la deuxième grappe esclave à destination du module API 102E dans une étape E1 .

Le module API 102E transmet alors, dans une étape E12', le fichier de configuration FC2 de la deuxième grappe esclave comprenant des paramètres de prise de contrôle et des conditions d'exécution attendues de ladite tâche par un nœud de calcul II,E de la deuxième grappe esclave, les conditions d'exécution attendues de la tâche étant identiques aux conditions d'exécution courantes de la même tâche par le nœud de calcul II,M de la grappe maître. Le fichier de configuration FC2 est créé au cours de l'exécution de l'étape E1 .

Un module API 102E d'un nœud de gestion 10E de la deuxième grappe esclave reçoit le fichier de configuration FC2 et le transmet à destination d'un module de synchronisation esclave 104E de la deuxième grappe esclave.

Le module de synchronisation esclave 104E de la deuxième grappe esclave vérifie, auprès d'au moins un nœud de calcul II,E de la deuxième grappe esclave la disponibilité des ressources requises pour l'exécution de la tâche identifiées dans le fichier de configuration FC2. Le module de synchronisation esclave 104E de la deuxième grappe esclave transmet le résultat de cette vérification à destination du module API 102E de la deuxième grappe esclave. Le module API 102E de la deuxième grappe esclave transmet à son tour cette information à la base de données 103Ede la deuxième grappe esclave qui met à jour ses registres.

Lorsque le module de synchronisation esclave 104E de la deuxième grappe esclave a déterminé que les ressources requises sont disponibles, il transmet un message de confirmation MC2 de la prise de contrôle de la deuxième grappe esclave par la première grappe esclave au module API 102E de la deuxième grappe esclave qui le transmet à son tour au module API 102E du nœud de gestion 10E de la première grappe esclave au cours d'une étape E13'.

Parallèlement, la deuxième grappe esclave met en œuvre une boucle d'orchestration telle que décrite en référence à la figure 4 afin de configurer l'ensemble des nœuds de calculs II,E de la deuxième grappe esclave aves les conditions d'exécution comprises dans le fichier de configuration FC2.

A l'issue de cette étape E13', la deuxième grappe esclave est contrôlée par la première grappe esclave, elle-même contrôlée par la grappe maître, et présente un fonctionnement identique à celui de la grappe maître. Enfin dans une étape E14', le module API 102E du nœud de gestion 10E de la première grappe esclave transmet le message de confirmation MC2 au module API 102M du nœud de gestion 10M de la grappe maître qui le transmet à son tour au module de synchronisation maître 104M.

Une fois la prise de contrôle de la deuxième grappe esclave effectué, la première grappe esclave transmet de manière récurrente des données relatives à l'exécution des tâches exécutées par les nœuds de calcul II,E de la deuxième grappe esclave à destination de la grappe maître.

Lorsque les circonstances l'exigent, par exemple lorsque le satellite embarquant la première grappe esclave ne survole plus le territoire dans lequel se situe la grappe maître, la première grappe esclave peut être affranchie et ainsi retrouver son indépendance afin d'être utilisée de manière autonome ou sous le contrôle d'une nouvelle grappe maître.

Dans une étape E13, le module API 102M de la grappe maître reçoit une demande d'affranchissement DA de première grappe esclave.

Dans une étape E14, cette demande d'affranchissement DA est transmise à la base de données 103M qui met à jour ses registres avec les informations comprises dans la demande d'affranchissement DA.

Au cours d'une étape E15, une boucle d'orchestration est mise en œuvre par la grappe maître.

Une fois la boucle d'orchestration mise en œuvre, le module de synchronisation maître 104M transmet une demande d'affranchissement DA2 de la première grappe esclave à destination du module API 102M dans une étape E16.

Le module API 102M transmet alors, dans une étape E17, un fichier de configuration FC3 de la première grappe esclave comprenant des paramètres d'affranchissement de ladite première grappe esclave.

Le module API 102E du nœud de gestion 10E de la première grappe esclave reçoit le fichier de configuration FC3 au cours d'une étape E18 et le transmet à destination du module de synchronisation esclave 104E.

Au cours d'une étape E19, le module de synchronisation esclave 104E traite le fichier de configuration FC3 et transmet le résultat de traitement à destination du module API 102E dans une étape E20. Le module API 102E transmet à son tour cette information à la base de données 103E qui met à jour ses registres.

Lorsque le module de synchronisation esclave 104E a traité le fichier de configuration FC3, il transmet un message d'affranchissement de la première grappe esclave au maître au module API 102E qui le transmet à son tour au module API 102M du nœud de gestion 10M de la grappe maître au cours d'une étape E21.

Parallèlement à l'exécution de l'étape E21, la première grappe esclave met en œuvre, dans une étape E22, une boucle d'orchestration telle que décrite en référence à la figure 4 afin de configurer l'ensemble des nœuds de calculs II,E de la première grappe esclave.

A l'issue de cette étape E21, la première grappe esclave n'est plus contrôlée par la grappe maître et fonctionne de manière autonome.

Une procédure identique peut être mise en œuvre entre la première grappe esclave et la deuxième grappe esclave afin de mettre fin au contrôle de la deuxième grappe esclave par la première grappe esclave. La [fig. 5] représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où, la première grappe esclave étant déjà contrôlée par la grappe maître, la configuration de la grappe maître est mise à jour. Typiquement l'enchaînement d'étapes décrit en référence à la figure 5 se situe entre les étapes E12 et E13 décrites en référence à la figure 3.

Dans une étape Fl, le module API 102M du nœud de gestion 10M de la grappe maître reçoit une demande de mise à jour MàJl de la configuration de la grappe maître. Une telle demande de mise à jour MàJl comprend un identifiant IdT d'au moins une tâche destinée à être exécutée par au moins un nœud de calcul II,M de la grappe maître. La demande de mise à jour MàJl peut être émise par un équipement d'un réseau de télécommunication géré par le même opérateur en télécommunication gérant la grappe maître. Une telle demande de mise à jour MàJl semblable à une demande de prise de contrôle telle que celle décrite en référence à la figure 3.

Un exemple d'une telle demande de mise à jour MàJl de la configuration est le suivant : apiVersion: apps/vx kind: DeploymentEsclave metadata: name: NameDeployement labels: app: LabelDeployement spec: replicas: NombreDeReplicat selector: matchLabels: app: LabelDeployement template: metadata: labels: app: LabelDeployement spec: esclave: IDESCLAVE/IPESCLAVE containers:

- name: NOMAPPLICATION image: NONCONTENEUR ports:

- containerPort: port resources: limits:

RESSOURCELIMITE requests:

RESSOURCEDEMANDE

Dans une étape F2, cette demande de mise à jour MàJl est transmise à la base de données 103M qui met à jour ses registres avec les informations comprises dans la demande de mise à jour MàJl telle que, en autre, un identifiant IdT d'au moins une tâche à exécuter par au moins un module de calcul II,M de la grappe maître et des informations relatives à des conditions d'exécution de la tâche par le nœud de calcul II,M.

Au cours d'une étape F3, une boucle d'orchestration est mise en œuvre par la grappe maître.

Une fois la boucle d'orchestration mise en œuvre, la configuration de la grappe maître est mise à jour. Suite à cette mise à jour de la configuration de la grappe maître, certaines tâches peuvent avoir changé de conditions d'exécution, de nouvelles tâches peuvent être exécutées et certaines tâches peuvent être terminées.

Le module de synchronisation maître 104M crée et transmet alors un fichier de mise à jour de configuration MàJFC de la première grappe esclave à destination du module API 102M dans une étape F4.

Le module API 102M transmet alors, dans une étape F5, le fichier de mise à jour de configuration MàJFC de la première grappe esclave comprenant des conditions d'exécution attendues de ladite tâche par nœud de calcul II,E, les conditions d'exécution attendues de la tâche étant identiques aux conditions d'exécution courantes de la même tâche par le nœud de calcul lliM, c'est-à-dire les conditions dans lesquelles les tâches sont exécutées par le nœud de calcul lliM suite à la mise en œuvre de la boucle d'orchestration à l'étape F3.

Le module API 102E du nœud de gestion 10E de la première grappe esclave reçoit le fichier de mise à jour de configuration MàJFC au cours d'une étape F6 et le transmet à destination du module de synchronisation esclave 104E.

Au cours d'une étape F7, le module de synchronisation esclave 104E vérifie, par exemple auprès d'au moins un nœud de calcul II,E la disponibilité des ressources requises pour l'exécution de la tâche identifiées dans le fichier de mise à jour de configuration MàJFC. Le module de synchronisation esclave 104E transmet le résultat de cette vérification à destination du module API 102E dans une étape F8. Le module API 102E transmet à son tour cette information à la base de données 103E qui met à jour ses registres dans une étape F9.

Si, dans un premier cas, le module de synchronisation esclave 104E a déterminé que les ressources requises sont disponibles, il transmet un message comprenant des informations relatives à la mise en œuvre de la mise à jour requise, dit message de confirmation MC de la mise à jour, de la première grappe esclave au module API 102E qui le transmet à son tour au module API 102M du nœud de gestion 10M de la grappe maître au cours d'une étape F10.

Parallèlement à l'exécution de l'étape F10, la première grappe esclave met en œuvre, dans une étape Fil, une boucle d'orchestration telle que décrite en référence à la figure 4 afin de configurer l'ensemble des nœuds de calculs II,E de la première grappe esclave aves les conditions d'exécution comprises dans le fichier de mise à jour de configuration émis par la grappe maître.

A l'issue de cette étape Fil, la première grappe esclave est mise à jour et présente un fonctionnement identique à celui de la grappe maître.

Enfin dans une étape F12, le module API 102M du nœud de gestion 10M de la grappe maître transmet le message de confirmation MC de la mise à jour au module de synchronisation maître 104M de la grappe maître.

Une fois la mise à jour de la première grappe esclave effectuée, la première grappe esclave transmet de manière récurrente des données relatives à l'exécution des tâches exécutées par ses nœuds de calcul II,E.

Si, dans un deuxième cas, au cours de l'étape F7, le module de synchronisation esclave 104E a déterminé que les ressources requises ne sont pas disponibles, le module de synchronisation esclave 104E transmet le résultat de cette vérification à destination du module API 102E dans l'étape F8. Le module API 102E transmet à son tour cette information à la base de données 103E qui met à jour ses registres dans l'étape F9. Lorsque le module de synchronisation esclave 104E a déterminé que les ressources requises ne sont pas disponibles, il transmet alors un message d'échec EC de la mise à jour de la première grappe esclave au module API 102E qui le transmet à son tour au module API 102M du nœud de gestion 10M de la grappe maître au cours de l'étape F10.

Dans un deuxième mode de réalisation dans lequel le nœud de gestion 10E de la première grappe esclave a été autorisé explicitement à prendre le contrôle de la deuxième grappe esclave par la première grappe esclave, la base de données 103E met à jour ses registres avec les résultats de la vérification au cours d'une étape F9'.

Au cours d'une étape F10', une boucle d'orchestration est mise en œuvre par la première grappe esclave afin d'instancier un module de synchronisation maître 104M dans le nœud de gestion 10E de la première grappe esclave.

Une fois la boucle d'orchestration mise en œuvre, le module de synchronisation maître 104M du nœud de gestion 10E de la première grappe esclave est instancié et transmet une demande de mise à jour de la deuxième grappe esclave à destination du module API 102E dans une étape FU'. La demande de mise à jour de la deuxième grappe esclave D3 comprend un fichier de mise à jour de configuration MàJFC2 de la deuxième grappe esclave créé par le module de synchronisation maître 104M.

Dans une autre implémentation dans laquelle le nœud de gestion 10E de la première grappe esclave comprend déjà un module de synchronisation maître 104M, le module de synchronisation maître 104M du nœud de gestion 10E transmet, directement après l'étape F7, une demande de mise à jour de la deuxième grappe esclave à destination du module API 102E dans une étape Fil'.

Le module API 102E transmet alors, dans une étape F12', le fichier de mise à jour de configuration MàJFC2 de la deuxième grappe esclave comprenant des conditions d'exécution attendues de ladite tâche par un nœud de calcul II,E de la deuxième grappe esclave, les conditions d'exécution attendues de la tâche étant identiques aux conditions d'exécution courantes de la même tâche par le nœud de calcul II,M de la grappe maître. Le fichier de configuration MàJFC2 est créé au cours de l'étape FU'.

Un module API 102E d'un nœud de gestion 10E de la deuxième grappe esclave reçoit le fichier de mise à jour de configuration MàJFC2 et le transmet à destination d'un module de synchronisation esclave 104E de la deuxième grappe esclave.

Le module de synchronisation esclave 104E de la deuxième grappe esclave vérifie, auprès d'au moins un nœud de calcul II,E de la deuxième grappe esclave la disponibilité des ressources requises pour l'exécution de la tâche identifiées dans le fichier de mise à jour de configuration MàJFC2. Le module de synchronisation esclave 104E de la deuxième grappe esclave transmet le résultat de cette vérification à destination du module API 102E de la deuxième grappe esclave. Le module API 102E de la deuxième grappe esclave transmet à son tour cette information à la base de données 103E de la deuxième grappe esclave qui met à jour ses registres.

Lorsque le module de synchronisation esclave 104E de la deuxième grappe esclave a déterminé que les ressources requises sont disponibles, il transmet un message de confirmation MC2 de la mise à jour de la deuxième grappe esclave au module API 102E de la deuxième grappe esclave qui le transmet à son tour au module API 102E du nœud de gestion 10E de la première grappe esclave au cours d'une étape F13'. Parallèlement, la deuxième grappe esclave met en œuvre une boucle d'orchestration telle que décrite en référence à la figure 4 afin de configurer l'ensemble des nœuds de calculs II,E de la deuxième grappe esclave aves les conditions d'exécution comprises dans le fichier de mise à jour de configuration MàJFC2.

A l'issue de cette étape F13', la deuxième grappe esclave est mise à jour et présente un fonctionnement identique à celui de la grappe maître.

Enfin dans une étape F14', le module API 102E du nœud de gestion 10E de la première grappe esclave transmet le message de confirmation MC2 au module API 102M du nœud de gestion 10M de la grappe maître qui le transmet à son tour au module de synchronisation maître 104M.

Une fois la mise à jour de la deuxième grappe esclave effectué, la première grappe esclave transmet de manière récurrente des données relatives à l'exécution des tâches exécutées par les nœuds de calcul II,E de la deuxième grappe esclave à destination de la grappe maître.

La [fig. 6] représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en œuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où, la première grappe esclave étant déjà contrôlée par la grappe maître, la grappe esclave détecte une erreur. Typiquement l'enchaînement d'étapes décrit en référence la figure 6 se situe entre les étapes E12 et E13 décrites en référence à la figure 3.

Dans une étape Hl, le module API 102E du nœud de gestion 10E de la première grappe esclave reçoit un message d'erreur Pb transmis par exemple par une antenne radio d'un nœud d'accès d'un réseau de communication, le nœud d'accès étant contrôlé par la première grappe esclave qui exécute pour lui des fonctions réseau telles que des fonctions de codage par exemple.

Dans une étape H2, le module API 102E du nœud de gestion 10E transmet le message d'erreur Pb à destination du module de synchronisation esclave 104E de la première grappe esclave.

Au cours d'une étape H3, le module de synchronisation esclave 104E vérifie la capacité de la première grappe esclave à résoudre l'erreur elle-même.

Si la première grappe esclave est capable de résoudre l'erreur elle-même, elle le fait au cours d'une étape H4.

Si la première grappe esclave n'est pas capable de résoudre l'erreur elle-même, le module de synchronisation esclave 104E transmet cette information à destination du module API 102E dans une étape H5.

Le module API 102E transmet à son tour cette information au module API 102M de la grappe maître dans une étape H6. Le module API 102M de la grappe maître transmet à son tour cette information au module de synchronisation maître 104M dans une étape H7.

Au cours d'une étape H8, le module de synchronisation maître 104M détermine une solution pour résoudre l'erreur et génère un fichier de correction.

Le module de synchronisation maître 104M transmet le fichier de correction au module API 102M dans une étape H9.

Le module API 102M transmet le fichier de correction à destination du module API 102E au cours d'une étape H10.

Le module de synchronisation esclave 104E reçoit, dans une étape Hll, le fichier de correction qui lui est transmis par le module API 102E. Au cours d'une étape H12, une boucle d'orchestration est mise en oeuvre par la grappe maître afin de prendre en compte les informations du fichier de correction lors de l'exécution des tâches par les noeuds de calcul II,M.

Au cours d'une étape H13, une boucle d'orchestration est mise en oeuvre par la première grappe maître afin de prendre en compte les informations du fichier de correction lors de l'exécution des tâches par les noeuds de calcul II,E et ainsi réparer l'erreur.

La [fig. 7] représente les étapes des procédés de contrôle et de configuration lorsqu'elles sont mises en oeuvre par les différents constituants d'une grappe maître et d'une première grappe esclave dans le cas où les messages échangés entre la grappe maître et la première grappe esclave sont relayés par un équipement intermédiaire.

Ainsi, lorsque le module API 102M souhaite transmette un fichier de configuration FC de première grappe esclave au cours de l'étape E5 ou un fichier de mise à jour de configuration MàJFC au cours de l'étape F5, le message comprenant ce fichier de configuration ou de mise à jour de configuration est transmis à destination d'un équipement intermédiaire qui sert alors de relai.

Dans une étape Jl, l'équipement intermédiaire R reçoit le message comprenant ce fichier de configuration ou de mise à jour de configuration destiné à être relayé à la première grappe esclave.

Au cours d'une étape J2, l'équipement intermédiaire R applique des règles de sécurité et de filtrage au message reçu. De telles règles sont par exemple fixées par l'opérateur de télécommunication gestionnaire de la grappe maître et souhaitant prendre le contrôle ou mettre à jour la première grappe esclave. L'équipement intermédiaire R vérifie également qu'il est en capacité de communiquer avec la première grappe esclave.

Si l'équipement intermédiaire R détermine que le message à transmettre à la première grappe esclave ne peut être relayé, il en informe la grappe maître au cours d'une étape J3 et indique les raisons de ce refus.

Si l'équipement intermédiaire R détermine que le message à transmettre à la première grappe esclave peut être relayé, il transmet le message à la première grappe esclave au cours d'une étape J4.

La grappe maître est informée de la bonne transmission du message à la première grappe esclave lorsque l'équipement intermédiaire lui transmet au cours d'une étape J5 un message de confirmation de la prise de contrôle de la première grappe esclave ou un message de confirmation de mise à jour de la première grappe esclave.

La [fig. 8] représente nœud de gestion 10 apte à mettre en œuvre les différents procédés objets de la présente invention.

Un nœud de gestion 10 peut comprendre au moins un processeur matériel 801, une unité de stockage 802, une interface 803, et au moins une interface de réseau 804 qui sont connectés entre eux au travers d'un bus 805 en plus du module API 102, du contrôleur 101, de la base données 103 et du/des modules de synchronisation 104. Bien entendu, les éléments constitutifs du nœud de gestion 10 peuvent être connectés au moyen d'une connexion autre qu'un bus.

Le processeur 801 commande les opérations du nœud de gestion 10. L’unité de stockage 802 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l'invention à exécuter par le processeur 801, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 801, des données intermédiaires de calculs effectués par le processeur 801, etc. Le processeur 801 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 801 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement (Central Processing Unit) qui exécute un programme stocké dans une mémoire de celui-ci.

L'unité de stockage 802 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 802 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture.

L'interface 803 fournit une interface entre le nœud de gestion 10 et au moins un nœud de calcul 11, appartenant à la même grappe de nœuds que le nœud de gestion 10.

L'interface réseau 804 fournit quant à elle une connexion entre le nœud de gestion 10 et un autre nœud de gestion d'une autre grappe de nœuds.