Titre : PROCEDE D’ORCHESTRATION D’APPLICATIONS LOGICIELLES DANS UN SYSTEME DE TELECOMMUNICATION, PROGRAMME D’ORDINATEUR ET DISPOSITIF D’ORCHESTRATION ASSOCIES

Domaine technique :

[0001 ] L’invention se situe dans le domaine de l’orchestration d’applications logicielles, dans laquelle des ressources matérielles, comprenant CPUs et mémoires, dans des serveurs délocalisés et répartis sont sélectionnées pour héberger l’exécution d’une application logicielle.

Technique antérieure :

[0002] Actuellement, les solutions d’orchestration des clouds civils évaluent l’adéquation d’un serveur pour héberger un logiciel en fonction de la ressource CPU disponible ou de la quantité de mémoire disponible sur ce serveur versus les besoins du logiciel en CPU et mémoire.

[0003] Si ces solutions sont tout à fait efficaces sur des réseaux de télécommunication gigabit à base de fibres optiques, elles se révèlent insuffisantes sur des réseaux de télécommunication contraints et peuvent même contribuer à un engorgement de ces réseaux.

[0004] On entend par « réseau de télécommunication contraint » un réseau de télécommunication dans lequel la capacité de télécommunication est limitée (comparée aux réseaux gigabits) et peu stable comme, par exemple, les réseaux de télécommunication tactiques déployés localement et ponctuellement sur un terrain d’intervention sanitaire ou militaire (une zone de catastrophe, géologique ou autre, une zone de conflit etc.). Les liaisons de transmission y sont fréquemment rompues sans préavis (par exemple par brouillage intentionnel ou non), certaines sont très limitées en termes de bande passante ou connaissent des occurrences, bien plus fréquentes que dans les réseaux grands publics classiques, de variations de bande passante ou de latence. Or il est besoin dans ces interventions de pouvoir faire exécuter des applications logicielles de façon fiable, notamment dans des serveurs embarqués dans des engins porteurs se déplaçant dans, sur ou à proximité de la zone d’intervention

[0005] Il existe donc un besoin de disposer d’une solution d’orchestration d’applications logicielles qui puisse être mise en oeuvre de façon satisfaisante sur tout type de réseau de télécommunication, y compris contraint.

Résumé de l’invention :

[0006] A cet effet, suivant un premier aspect, la présente invention décrit un procédé d’orchestration d’applications logicielles dans un système de télécommunication comprenant un dispositif électronique d’orchestration, des plateformes de télécommunication réparties (20), connectées à des liaisons d’un réseau de télécommunication sans fil et comprenant chacune des ressources de traitement parmi des ressources de mémoire et des ressources de calcul, ledit procédé comprenant les étapes suivantes mises en oeuvre par le dispositif d’orchestration : collecte d’états des ressources de traitement, lesdits états indiquant la disponibilité courante desdites ressources ; réception de requêtes indiquant des applications logicielles à exécuter et, pour chaque application logicielle indiquée dans une requête reçue, obtention des caractéristiques de mémoire et de calcul requises pour l’exécution de ladite application ; pour chaque application logicielle : sélection, parmi les plateformes, d’au moins une plateforme pour l’exécution de ladite application logicielle via une ressource de traitement de la plateforme sélectionnée, ladite sélection étant effectuée en fonction d’au moins: les états de disponibilité collectés des ressources de traitement ; et les caractéristiques obtenues de mémoire et de calcul requises pour l’exécution de ladite application; et affectation d’au moins ladite plateforme sélectionnée pour l’exécution de ladite application logicielle ; ledit procédé étant caractérisé en ce qu’il comprend en outre les étapes suivantes mises en oeuvre par le dispositif d’orchestration : collecte de conditions courantes de transport sur ledit réseau de télécommunication sans fil, lesdites conditions de transport indiquant au moins une information associée aux liaisons parmi leur bande passante disponible, leur gigue, leur latence, leur taux d’erreur, leur bande passante nominale et leur taux d’occupation ; pour chaque application logicielle indiquée dans une requête reçue, obtention en outre de gabarit(s) de transport indiquant des conditions de transport minimales requises pour la mise en oeuvre de télécommunications avec ladite application logicielle pendant son exécution ; ladite sélection de la plateforme est effectuée en outre en fonction des conditions de transport collectées et desdits gabarit(s) de transport obtenus.

[0007] Dans des modes de réalisation, un tel procédé comprendra en outre l’une au moins des caractéristiques suivantes :

[0008] - ladite requête reçue relative à ladite application logicielle indique en outre des exigences de déploiement pour l’installation de ladite application logicielle ; et ladite sélection de ressource de traitement est effectuée en outre en fonction desdites exigences de déploiement pour l’installation de ladite application logicielle ;

[0009] - dans une structure arborescente, deux applications logicielles sont reliées par une branche de ladite structure si elles ont été définies pour mettre en oeuvre entre elles des télécommunications lors de leur exécution et à chaque branche sont associées des gabarits de transport requis spécifiquement pour lesdites télécommunications et selon lequel : la sélection d’au moins une plateforme pour l’exécution d’une application logicielle, quand elle fait partie de ladite structure arborescente comprend en outre au moins la sélection d’une plateforme pour l’exécution d’une autre application de ladite structure arborescente, lesdites plateformes devant être une seule et même plateforme, en fonction d’une règle relative aux gabarits de transport sur les branches les reliant, si cela diminue le besoin d’échanges de la plateforme sélectionnée avec les autres plateformes ; [0010] - suite à ladite sélection, il est déclenché une réservation de ressources de transport sur au moins une liaison du réseau de télécommunication sans fil en fonction desdits gabarit(s) de transport et des conditions courantes de transport, pour la mise en oeuvre de télécommunications avec ladite application logicielle pendant son exécution ;

[0011] - lesdits gabarits de transport pour la mise en oeuvre de télécommunications avec ladite application logicielle pendant son exécution comprennent un premier gabarit de transport correspondant à un mode de fonctionnement nominal de l’application logicielle et un deuxième gabarit de transport, moins exigeant que le premier gabarit de transport , correspondant à un mode de fonctionnement dégradé de l’application logicielle ; ladite sélection de ressource de traitement étant effectuée en fonction desdits premier et deuxième gabarits de transport tels qu’obtenus.

[0012] Suivant un autre aspect, l’invention décrit un programme d’ordinateur destiné à être stocké dans la mémoire d’un dispositif électronique d’orchestration comprenant en outre un microcalculateur, ledit programme d’ordinateur comprenant des instructions qui, lorsqu’elles sont exécutées sur le microcalculateur, mettent en oeuvre les étapes d’un procédé suivant le premier aspect de l’invention.

[0013] Suivant un autre aspect, l’invention décrit un dispositif électronique d’orchestration d’applications logicielles pour un système de télécommunication comprenant des plateformes de télécommunication réparties, connectées à des liaisons d’un réseau de télécommunication sans fil et comprenant chacune des ressources de traitement parmi des ressources de mémoire et des ressources de calcul, ledit dispositif d’orchestration étant adapté pour collecter des états des ressources de traitement, lesdits états indiquant la disponibilité courante desdites ressources, pour recevoir des requêtes indiquant des applications logicielles à exécuter et, pour chaque application logicielle indiquée dans une requête reçue, pour obtenir des caractéristiques de mémoire et de calcul requises pour l’exécution de ladite application ; pour chaque application logicielle, ledit dispositif d’orchestration étant adapté pour : - sélectionner parmi les plateformes, au moins une plateforme pour l’exécution de ladite application logicielle via une ressource de traitement de la plateforme sélectionnée, ladite sélection étant effectuée en fonction d’au moins : les états de disponibilité collectés des ressources de traitement ; et les caractéristiques obtenues de mémoire et de calcul requises pour l’exécution de ladite application ; et

- pour affecter au moins ladite plateforme sélectionnée pour l’exécution de ladite application logicielle ; ledit dispositif d’orchestration étant caractérisé en ce qu’il est adapté pour :

- collecter des conditions courantes de transport sur ledit réseau de télécommunication sans fil, lesdites conditions de transport indiquant au moins une information associée aux liaisons parmi leur bande passante disponible, leur gigue, leur latence, leur taux d’erreur, leur bande passante nominale et leur taux d’occupation ;

- pour chaque application logicielle indiquée dans une requête reçue, obtenir en outre des gabarit(s) de transport indiquant des conditions de transport minimales requises pour la mise en oeuvre de télécommunications avec ladite application logicielle pendant son exécution ; ladite sélection de la plateforme étant effectuée en outre en fonction des conditions de transport collectées et desdits gabarit(s) de transport obtenus.

[0014] Dans des modes de réalisation, un tel dispositif comprendra en outre l’une au moins des caractéristiques suivantes :

[0015] - ladite requête reçue relative à ladite application logicielle indique en outre des exigences de déploiement pour l’installation de ladite application logicielle ; et ladite sélection de ressource de traitement est effectuée en outre en fonction desdites exigences de déploiement pour l’installation de ladite application logicielle ;

[0016] - dans une structure arborescente, deux applications logicielles sont reliées par une branche de ladite structure si elles ont été définies pour mettre en oeuvre entre elles des télécommunications lors de leur exécution et à chaque branche sont associées des gabarits de transport requis spécifiquement pour lesdites télécommunications et selon lequel : la sélection d’au moins une plateforme pour l’exécution d’une application logicielle, quand elle fait partie de ladite structure arborescente comprend en outre au moins la sélection d’une plateforme pour l’exécution d’une autre application de ladite structure arborescente, lesdites plateformes devant être une seule et même plateforme, en fonction d’une règle relative aux gabarits de transport sur les branches les reliant, si cela diminue le besoin d’échanges de la plateforme sélectionnée avec les autres plateformes ;

[0017] - le dispositif est adapté pour, suite à ladite sélection, déclencher une réservation de ressources de transport sur au moins une liaison du réseau de télécommunication sans fil en fonction desdits gabarit(s) de transport et des conditions courantes de transport, pour la mise en oeuvre de télécommunications avec ladite application logicielle pendant son exécution.

Brève description des figures :

[0018] L’invention sera mieux comprise et d’autres caractéristiques, détails et avantages apparaîtront mieux à la lecture de la description qui suit, donnée à titre non limitatif, et grâce aux figures annexées, données à titre d’exemple.

[0019] [Fig. 1] La figure 1 est une illustration d’un système de télécommunication 1 dans un mode de réalisation de l’invention ;

[0020] [Fig. 2] La figure 2 représente des étapes d’un procédé d’allocation de ressources dans un mode de réalisation de l’invention ;

[0021] [Fig. 3] La figure 3 représente des étapes d’un procédé d’allocation de ressources dans un autre mode de réalisation de l’invention.

[0022] Des références identiques peuvent être utilisées dans des figures différentes lorsqu’elles désignent des éléments identiques ou comparables.

Description détaillée :

[0023] La figure 1 représente un système de télécommunication 1 dans un mode de réalisation de l’invention.

[0024] Le système 1 comprend un dispositif d’orchestration 10, une pluralité de plateformes de traitement 20. Dans un mode de réalisation ici représenté, le système 1 comprend en outre une base de données 50.

[0025] Chaque plateforme de traitement 20 est une plateforme matérielle qui comporte un ou des serveurs 6, un réseau de télécommunication local 7, un contrôleur électronique local 8 et une base de stockage de données 9. Le réseau de télécommunication local, par exemple un réseau filaire, interconnecte entre eux les serveurs 6 et le contrôleur local, au sein de leur plateforme 20.

[0026] Dans le cas représenté sur la figure 1 , le système 1 comprend trois plateformes de traitement 20 : les plateformes 20_1 , 20_2 et 20_3, par exemple embarquées chacune dans un engin mobile respectif (avion, drone, engin roulant)... : la plateforme 20_1 se trouve ici dans un avion, la plateforme 20_2 dans un autre avion et la plateforme 20_3 dans un véhicule terrestre, qui circulent au niveau d’une zone géographique d’intervention.

[0027] Dans le mode de réalisation considéré :

- la plateforme 20_1 comporte deux serveurs 6 : les serveurs SERV11 et SERVI 2 ;

- la plateforme 20_2 comporte trois serveurs 6 : les serveurs SERV21 , SERV22 et SERV23 ;

- et la plateforme 20_3 comporte un serveur 6 : le serveur SER31 .

[0028] La base de données de stockage 9 stocke, en association avec l’identifiant de chaque application logicielle à héberger considérée dans la présente invention, le code (binaire) de l’application et un ensemble de méta-données relatives à l’application logicielle.

[0029] La base de données 50 est par exemple dans un bâtiment distant de la zone d’intervention.

[0030] Le dispositif d’orchestration 10, appelé ci-après orchestrateur 10, est connecté par une liaison de télécommunication sans fil 61 , respectivement 62, respectivement 63, à la plateforme de traitement 20_1 , respectivement 20_2, respectivement 20_3.

[0031] Par ailleurs, les plateformes de traitement 20, ou au moins certaines d’entre elles, sont par exemple interconnectées entre elle et/ou avec d’autres entités de télécommunication sans fil (par exemple dans le cas présent la base de données 50) par un réseau de télécommunication sans fil contraint. Par exemple, dans le cas représenté en figure 1 , chaque plateforme 20J, i = 1 à 3, est reliée par une liaison satellite 5i à la base de données 50 ; la plateforme 20_1 est connectée à la plateforme 20_2 par une liaison 40, par exemple VHF ou UHF et la plateforme 20_2 est connectée à la plateforme 20_3 par une liaison 41 par exemple VHF et UHF.

[0032] Ces liaisons 40, 41 , 51 , 52, 53 constituent des ressources de transmission du réseau de télécommunication contraint du système 1 . [0033] Dans un mode de réalisation, certaines ou toutes les liaisons parmi les liaisons 40, 41 , 61 , 62 et 63 sont des liaisons logiques portées par une seule liaison physique.

[0034] L’orchestrateur 10 est adapté pour recevoir régulièrement, par exemple au moins une fois toutes les T _t secondes, des données indiquant les conditions courantes de transport sur les liaisons 40, 41 , 51 , 52 et 53, notamment la bande passante disponible et/ou le taux d’occupation des liaisons et/ou la latence et/ou la gigue.

[0035] Concernant la valeur de T _t : si l’on veut être réactif, il faut une valeur faible, par exemple, la valeur de T _t sera fixée égale au maximum à 1 seconde, mais cela va nécessiter une grande bande passante ; plus on augmentera cette valeur (jusqu’à par exemple 60 secondes), moins on consommera de bande passante, mais moins on sera réactif ; il y a donc un compromis à faire entre la consommation et la réactivité.

[0036] Dans un autre mode de réalisation, certaines au moins de ces données ne sont pas communiquées de façon périodique mais sur occurrence d’un événement (par exemple passage de la bande passante sous (ou au-dessus) de seuils définis etc., ce qui permet de minimiser l’empreinte de ces remontées sur la bande passante globale du réseau.

[0037] Ces données indiquant les conditions courantes de transport sont par exemple déterminées par les contrôleurs locaux 8 des plateformes 20 en fonction des échanges mis en oeuvre sur les liaisons de télécommunication, puis transmises au dispositif d’orchestration 10 par la plateforme 20_1 sur la liaison 6i, i = 1 à 3.

[0038] Typiquement, les liaisons UHF, VHF 40, 41 ont des bandes passantes fluctuantes et limitées, par exemple, fréquemment -voire toujours- inférieures à une centaine de kbits/s ou même à quelques dizaines de kbits/s ; les liaisons satellite 51 , 52 et 53 ont une bande passante fréquemment -voire toujours- inférieure à quelques Mbits/s (par exemple moins de 10) ou même quelques centaines de kbit/s (moins de 10).

[0039] La latence pour les satellites géostationnaires est d’environ 600ms (cas du double bond quand il faut repasser par un hub au sol) ; la latence pour les réseaux UHF est plutôt de l’ordre de la centaine de ms, peut-être quelques dizaines (moins de 10) de ms. Pour les satellites en orbite basse, la latence se situe entre les deux.

[0040] La gigue va surtout se retrouver sur les réseaux radio TDMA car le temps d’accès au slot d’émission est variable. Elle dépend de la longueur du slot, mais elle peut être de plusieurs dizaines (moins de 10 dizaines) de ms, voire plus.

[0041] Chaque serveur 6 comprend des ressources de traitement, qui comportent des ressources de calcul (CPU) et des ressources de mémoire par exemple de type RAM, ou NAS (Network- Attached Storage). Chaque serveur 6 est adapté pour héberger, pour un temps déterminé, une ou des applications logicielles suite à l’affectation de ressources de traitement du serveur 6 à chacune de ces applications logicielles, les applications hébergées s’exécutant alors en utilisant les ressources de mémoire et calcul qui lui ont été affectées.

[0042] Au sein de chaque plateforme 20J, i = 1 à 3, le contrôleur local 8 est adapté pour déterminer en temps réel pour chaque serveur 6 de cette plateforme 20J, l’état courant de disponibilité des ressources de traitement du serveur : quantité de ressources de mémoire disponible, par exemple exprimée en octets, et quantité de ressources de calcul disponible, par exemple exprimée en virtual CPU (vCPU) ou en threads ou en Mips (Million d’instructions par seconde), les autres ressources étant utilisées pour l’exécution d’applications logicielles affectées au serveur. On entend par « quantité de ressource disponible » la quantité qui pourrait être attribuée à l’exécution d’une application logicielle supplémentaire. Le contrôleur local 8 est adapté pour déterminer en temps réel pour chaque serveur 6 de cette plateforme 20J, l’état des applications s’exécutant sur le serveur 6 (par exemple déroulement de l’exécution OK ou NOK, état d’avancement, performances ...).

[0043] Le contrôleur local 8 est adapté pour transmettre régulièrement, par exemple au moins une fois toutes les T _r secondes, avec T _r par exemple choisi égal à T _t , l’état des ressources de traitement à l’orchestrateur 10 ainsi que l’état des applications.

[0044] Dans un autre mode de réalisation, la transmission de cet état n’est pas périodique mais a lieu sur occurrence d’un événement par exemple lié à un dépassement de seuil(s) caractérisant l’état des ressources et/ou l’état des applications. [0045] L’orchestrateur 10 est un dispositif électronique comprenant un bloc électronique d’ordonnancement 11 , un bloc électronique de sélection 12 et une base de données 13. Il est adapté pour recevoir des requêtes, nommées REQ, depuis des dispositifs de télécommunication connectés à l’orchestrateur 10 par des liaisons de télécommunication. Certains de ces dispositifs de communication sont par exemple embarqués dans les engins mobiles transportant les plateformes 20 ou embarqués dans le même engin, mobile ou fixe, dans lequel est situé l’orchestrateur 10.

[0046] Le bloc de sélection 12 de l’orchestrateur 10 est adapté pour, suite à la réception d’une requête, nommée REQ, indiquant une application logicielle à exécuter, sélectionner parmi l’ensemble des ressources de traitement des serveurs des plateformes 20_1 , 20_2, 20_3, celle(s) des ressource(s) de traitement qui sera(seront) affectée(s) à l’exécution d’une application logicielle indiquée dans la requête REQ, de la manière décrite plus en détail en référence aux figures 2 et 3.

[0047] Chaque requête REQ reçue par l’orchestrateur 10 et concernant une application logicielle à héberger, nommée APP, est conforme à une syntaxe prédéfinie et comporte au moins, outre l’identifiant du dispositif de télécommunication à l’origine de la requête, l’identifiant de l’application logicielle APP et optionnellement indication temporelle de quand l’exécution de l’application APP est souhaitée (par exemple au plus tard).

[0048] A partir de cet identifiant d’application logicielle APP, l’orchestrateur 10 est adapté pour obtenir les informations suivantes (ou certaines au moins des informations suivantes), stockées préalablement, dans sa base de données 14, en correspondance avec l’identifiant de l’application logicielle APP (par exemple ces informations font partie des méta-données de l’application APP) : a/ code (binaire) de l’application logicielle APP les valeurs de paramètres etc. (ou dans un mode de réalisation, l’adresse URL à partir de laquelle l’application logicielle peut être téléchargée) ; b/ les caractéristiques de mémoire et de calcul requises, nécessaires à la bonne exécution de l’application logicielle APP obtenues par l’évaluation des quantités de ressources de calcul et de mémoire par exemple au moment de la conception de l’application APP) c/ indication des conditions de transport minimales requises pour la mise en oeuvre de télécommunications avec ladite application logicielle APP pendant son exécution ; cette indication est fournie dans un mode de réalisation pour un mode nominal de fonctionnement de l’application et optionnellement en outre pour un ou plusieurs modes dégradés de fonctionnement de l’application logicielle ; ces conditions sont exprimées par exemple sous forme de bande passante minimale requise, de latence maximale requise, de gigue maximale requise, de taux d’erreur maximal requis, de coût d’usage maximal permis, de paramètres qualitatifs (type de liaison par exemple), etc.

[0049] Dans un autre mode de réalisation, les informations indiquées ci-dessus comme extraites d’une base de données 13 sont alternativement indiquées dans la requête REQ et l’orchestrateur les obtient directement dans la requête REQ.

[0050] Ainsi, pour chaque application logicielle destinée à être traitée par l’orchestrateur 10, il devra préalablement, par exemple lors de la conception de chaque application logicielle APP, être effectuée une étape de caractérisation des échanges mis en oeuvre par l’application logicielle, notamment en émission. Cette étape est par exemple mise en oeuvre par un bloc logiciel de caractérisation mettant en oeuvre les étapes ci-dessous.

[0051 ] Dans cette caractérisation des échanges, les types d’information échangées sont tout d’abord identifiés. Pour chaque type d’information, la durée de vie de l’information produite est alors caractérisée. Cela donne une contrainte de latence à ne pas dépasser sur le transport de cette information. Ensuite, la volumétrie de l’information produite par ces échanges est calculée ou évalué ou mesurée. Associée à la contrainte de latence maximum, cela conduit à une contrainte de bande passante minimum nécessaire pour véhiculer l’information produite. La périodicité des échanges est une autre propriété de l’information qui permet de maintenir les ressources dans le temps. Pour une information non périodique, une fois l’information envoyée, les ressources de transmission peuvent être libérées. Pour une information périodique, les ressources doivent être maintenues tant que l’application est active. Par ailleurs, la volumétrie associée à la période permet de définir un débit moyen d’information, ce qui conduit à une contrainte de bande passante minimum sur les ressources de transmission. [0052] Lors de cette caractérisation, dans un mode de réalisation, les données ci- dessous, ou au moins de certaines d’entre elles sont en outre déterminées : contrainte de gigue, c’est-à-dire une contrainte sur la variation maximum de latence ; contrainte sur le taux de perte maximum d’information, ce qui se traduit en un taux d’erreur maximum du réseau de transmission ; éléments qualitatifs du transport : liaison sécurisée nécessaire ou pas, liaison patrimoniale nécessaire ou pas, ....

[0053] De cette caractérisation des échanges associés à l’application logicielle, il est ainsi aisément déduit une définition des conditions de transport seuil requises pour la bonne exécution de l’application logicielle, en termes d’au moins de valeur minimale de bande passante et/ou valeur maximale de latence et/ou gigue et/ou taux d’erreur.

[0054] Comme précisé plus haut, cette caractérisation des échanges (et des conditions de transport seuil requises) est réalisée au moins pour un mode nominal de fonctionnement de l’application et en outre, optionnellement, pour un ou plusieurs modes dégradés de fonctionnement de l’application logicielle qui pourront être mis en oeuvre en cas de raréfaction ou dégradation des ressources de transmission du réseau.

[0055] Par exemple, une application de capture vidéo sera associée à un mode de fonctionnement nominal, dans lequel elle fournit des images avec une résolution maximale, correspondant à un débit de 2 Mbit/s, un premier mode de fonctionnement dégradé dans lequel elle fournit des images avec une résolution intermédiaire, correspondant à un débit de 1 Mbit/s et un deuxième mode de fonctionnement dégradé dans lequel elle fournit des images avec une résolution basse, correspondant à un débit de 500 kbit/s. Cela permet ainsi à l’application de basculer dans un mode de fonctionnement adapté si une ressource de transmission permettant le mode de fonctionnement nominal ne peut être trouvée.

[0056] Les informations correspondant à l’item c ci-dessus peuvent ainsi prendre plusieurs formes : soit elles sont fournies sous la forme de l’évaluation des échanges (et dans ce cas, c’est l’orchestrateur qui effectue la traduction, en en déduisant les conditions de transport seuil requises (= gabarits de transport à respecter), soit sous la forme de ces gabarits de transport à respecter (différents modes de fonctionnement correspondant à différents gabarits de transport).

[0057] Les applications logicielles sont des unités logicielles d’exécutable autonome (comprenant donc le code), par exemple de type containers, tels que les pods Kuberbetes®. Chacune est adaptée pour être déployée sur un serveur choisi par l’orchestrateur 10, et pour y être exécutée.

[0058] Dans un système 1 selon l’invention, les conditions courantes de transport sont donc supervisées et fournies à l’orchestrateur 10 au même titre que les ressources de calcul et de mémoire, et la sélection de la ressource matérielle d’hébergement des applications prend en compte non seulement la capacité de calcul et la mémoire nécessaire à l’exécution des applications, mais également la capacité du réseau contraint sous-jacent à assurer les échanges réalisés par les applications du fait de leur délocalisation.

[0059] La figure 2 représente les étapes d’un procédé d’orchestration d’applications logicielles dans un mode de réalisation de l’invention.

[0060] Dans le mode de réalisation considéré, l’orchestrateur 10, et notamment le bloc d’ordonnancement 11 et le bloc de sélection 12, sont réalisés sous la forme de blocs logiciels, comportant des instructions logicielles stockées dans une mémoire de l’orchestrateur 10 et qui, lorsqu’elles sont exécutées sur un processeur de l’orchestrateur 10, mettent en oeuvre les étapes leur incombant.

[0061] En référence à la figure 2, le contrôleur 8 dans chaque plate-forme 20 détermine dans une étape 101 a, en fonction de données de contrôle transmises par les ressources matérielles de traitement (mémoire et calcul) de chaque serveur 6 de la plateforme, l’état actualisé de disponibilité des ressources de traitement de la plateforme, par exemple à une fréquence T _r (certaines des ressources ne sont par exemple pas disponibles, utilisées pour l’exécution des applications APP_A, APP_B, ... précédemment affectées aux ressources de cette plateforme 20 ).

[0062] En parallèle par exemple, le contrôleur 8 dans chaque plate-forme 20, détermine, dans une étape 101 b, l’état actualisé des applications logicielles s’exécutant localement, en fonction de données de contrôle qui lui sont transmises par ces applications logicielles dont l’exécution a été affectée aux serveurs 6 de la plateforme par l’orchestrateur 10 (à ce stade l’application APP_N n’est pas encore hébergée sur la plateforme, l’état ne la concerne donc pas ; elle a été encadrée en pointillés sur la figure 2 pour signaler son insertion ultérieure au cours du procédé).

[0063] Dans une étape 102a, le contrôleur 8 transmet l’état actualisé de disponibilité, également à la fréquence T _r (sur la liaison 6i depuis la plateforme 20J, i= 1 à 3) à l’orchestrateur 10, qui le reçoit. Dans un mode de réalisation, il transmet aussi à l’orchestrateur l’état des applications logicielles (optionnellement cet état est transmis seulement quand l’état indique un dysfonctionnement).

[0064] En parallèle par exemple, dans une étape 102b, l’orchestrateur 10 reçoit, par exemple (cf plus haut) à la fréquence T _t , les conditions courantes de transport sur les liaisons 40, 41 , 51 , 52 et 53.

[0065] Dans une étape 103, l’orchestrateur 10 reçoit une requête REQ, relative à une application logicielle, nommée ici APP_N, pour le déploiement de cette dernière sur un serveur à identifier par l’orchestrateur 10. Le bloc d’ordonnancement 11 de l’orchestrateur 10, dans une étape 104, extrait de la base de données 13 les informations indiquées (ou certaines d’entre elles) aux items a, b, c plus haut (quand elles ne figurent pas dans la requête REQ), puis il les fournit, ainsi que la requête REQ au bloc de sélection 12 de l’orchestrateur 10.

[0066] Le bloc de sélection 12, dans une étape 105, sélectionne celle des plateformes 20_1 , 20_2, 20_3 parmi l’ensemble des plateformes 20_1 , 20_2, 20_3 dont les ressource(s) de traitement pourront être affectées à l’exécution de l’application logicielle APP_N, cette sélection étant effectuée en fonction d’au moins : les états de disponibilité des ressources de traitement reçues à l’étape 102a ; les caractéristiques de mémoire et de calcul requises pour l’exécution de l’application APP_N, telles que fournies à l’étape 104 au bloc de sélection 12 ; les conditions de transport reçues à l’étape 102b ; les conditions de transport seuil telles que fournies à l’étape 104 au bloc de sélection 12.

[0067] Une fois la plateforme sélectionnée, si elle comporte plusieurs serveurs présentant les ressources requises, un serveur parmi ces serveurs est à son tour sélectionné, dont les ressources de traitement seront affectées à l’exécution de l’application logicielle APP_N, Cette dernière sélection est effectuée suivant les modes de réalisation, soit par le bloc de sélection 12 également, soit par le contrôleur local 8 de la plateforme sélectionnée.

[0068] Typiquement, les règles de sélection sont telles que : les ressources de traitement (calcul, mémoire au sens RAM) sélectionnées pour l’application APP_N seront choisies au sein d’un même serveur 6; les ressources sélectionnées sont des ressources, dans un état alors « disponible », et sont sélectionnées en quantité égale ou supérieure auxdites caractéristiques de mémoire et de calcul requises pour APP_N ; en outre la plateforme sélectionnée est telle que la ou les liaisons en sortie de cette plateforme (permettant l’émission de données depuis cette plateforme) présentent des conditions de transport (d’après celles reçues à l’étape 102b) vérifiant les conditions de transport seuil associées à l’application APP_N et fournies à l’étape 104

[0069] Des règles de sélection sont par exemple : identifier les plateformes en capacité d’héberger l’application APP_N selon remontée des états 102a ; sélectionner parmi elles la plateforme offrant les meilleures conditions de transport selon remontée 102b ; ou identifier les plateformes en capacité d’assurer les échanges de l’application APP_N selon remontée 102b ; sélectionner parmi elles la plateforme capable d’héberger l’application APP_N selon remontée des états 102a et qui conserve un maximum de ressources disponibles.

[0070] Considérons à titre d’exemple une application vidéo avec un mode de fonctionnement nominal (MdFO) à 2Mbit/s, un mode de fonctionnement dégradé MdF1 à 1 Mbit/s et un mode de fonctionnement dégradé MdF2 à 500kbit/s. Les conditions de transport (étape 102b) sont : liaison 51 = 2,4 Mbit/s ; liaison 52 = 750 kbit/s ; liaison 53 = 1 ,3 Mbit/s. Supposons que la plateforme 20_1 n’ait pas les ressources de calcul ou de mémoire suffisantes pour héberger APP_N et que les deux plateformes 20_2 et 20_3 puissent le faire, alors la sélection se portera sur la plateforme 20_3 qui offre les meilleures conditions de transport et l’application APP_N sera alors déployée en mode MdF1 . Si, en revanche, l’application 20_1 avait pu héberger l’application APP_N, alors c’est elle qui aurait été sélectionnée et l’application APP_N aurait été déployée en mode MdFO. [0071] Une mesure supplémentaire permettant de limiter l’usage des ressources de transmission consiste à modifier l’algorithme de scheduling de l’orchestrateur pour associer au déploiement tout ou partie des services support nécessaires au bon fonctionnement des services déployés et ainsi maintenir le maximum d’interactions colocalisées : ainsi si l’application APP_N doit échanger d’une part avec la base de données 50 et d’autre part avec une application qui est alors hébergée sur la plateforme 20_3, les volumes échangées avec cette dernière étant élevés et avec une durée de vie faible, le bloc de sélection 12 sélectionnera en priorité des ressources pour APP_N sur la plateforme 20_3

[0072] Puis le bloc de sélection 12 indique la plateforme sélectionnée (voire les ressources de calcul et mémoire sélectionnées) au bloc d’ordonnancement 11 .

[0073] Dans une étape 106, le bloc d’ordonnancement 11 transmet une demande d’hébergement de l’application APP_N au contrôleur local 8 de la plateforme 20 sélectionnée et fournit les informations de contexte (ou les informations permettant le téléchargement du contexte).

[0074] Dans une étape 107, le contrôleur 8 reçoit la demande d’hébergement de l’application APP_N ; il extrait de la base de données de stockage 9 notamment le code de l’application APP_N qui y est stocké en association avec l’identifiant de APP_N indiqué dans la demande d’hébergement. Le cas échéant, le contrôleur 8 sélectionne les ressources de calcul et mémoire locales (si elles n’ont pas été sélectionnées par le bloc de sélection 12 et indiquées dans la demande d’hébergement) en fonction des métadonnées de l’application APP_N dans la base 9. Le contrôleur 8 installe l’application dans la ressource mémoire (DRAM) sélectionnée, démarre cette application sur la ressource de calcul sélectionnée et vérifie l’exécution (utilisant les ressources de mémoire et de calcul sélectionnées). Il ajoute l’application APP_N à la liste des applications dont l’état de fonctionnement est remonté à l’orchestrateur (voir plus haut). L’application APP_N (encadrée en pointillés sur la figure 2 pour signaler son insertion au cours du procédé) est alors hébergée sur la plateforme.

[0075] L’application APP_N lors de son exécution met en oeuvre des échanges sur une ou des liaisons, parmi les liaisons 40, 41 , 51 , 52, 53, entre la plateforme 20 hébergeant APP_N et l’interlocuteur ou les interlocuteurs impliqués dans ces échanges.

[0076] Dans un mode de réalisation, le bloc d’ordonnancement 11 du dispositif d’orchestration déclenche, préalablement (par exemple, lors d’une étape 108), une action pour garantir la disponibilité de ressources de transport (estimées en fonction desdites conditions de transport seuil requises pour APP_N) nécessaires à ces échanges sur cette ou ces liaisons et permettant de satisfaire le mode de fonctionnement retenu : par exemple une réservation de ces ressources ou tout autre mécanisme permettant de gérer la qualité de service dans un réseau sans fil. Par la suite, si les conditions de transport évoluent, cela peut amener l’application APP_N à basculer sur un autre mode de fonctionnement. Il se peut aussi qu’aucun mode de fonctionnement ne peut être satisfait, auquel cas, l’application APP_N ne peut plus s’exécuter correctement. Une erreur d’exécution est alors remontée à l’ordonnanceur pour trouver un hébergement alternatif

[0077] La sélection de la ressource matérielle de traitement est fonction, dans un mode de réalisation, du délai de déploiement de l’application logicielle sur la ressource matérielle (incluant notamment l’instanciation de l’application, son démarrage, et la transmission du contexte de fonctionnement en cas de redéploiement), qui dépendent des conditions courantes de transport. Le délai de déploiement peut en effet se révéler incompatible du besoin temporel, exprimé dans la requête, pour bénéficier du service et doit donc être considéré dans l’algorithme de sélection des ressources de traitement disponibles.

[0078] Par exemple, dans un mode de réalisation, ladite requête REQ reçue relative à l’application logicielle à héberger indique en outre des exigences de déploiement pour l’installation de l’application logicielle (par exemple, il faut qu’elle soit lancée en 2 s). Et l’orchestrateur sélectionne le serveur 6 en fonction en outre de ces exigences de déploiement pour l’installation de l'application logicielle.

[0079] La figure 3 représente les étapes d’un procédé d’orchestration des applications dans un mode de réalisation de l’invention, dans le cas d’un redéploiement suite à la perte d’une ressource de traitement alors utilisée pour l’exécution d’une application logicielle ou suite à l’impossibilité à assurer l’un des modes de fonctionnement autorisés pour l’exécution d’une application. [0080] Le contrôleur 8 dans chaque plate-forme 20 (notamment dans les plateformes 20_1 , 20_2 représentées en figure 3) détermine dans une étape 201a, en fonction de données de contrôle transmises par les ressources matérielles de traitement de chaque serveur 6 de la plateforme, l’état actualisé de disponibilité des ressources de traitement de la plateforme, à une fréquence T _r (certaines des ressources ne sont pas disponibles, utilisées pour l’exécution des applications APP_A, ... APP_B, précédemment affectés aux ressources de cette plateforme 20).

[0081] En parallèle par exemple, dans une étape 201 b, le contrôleur 8 dans chaque plate-forme 20 détermine en fonction de données de contrôle transmises par les applications logicielles dont l’exécution a été affectée aux serveurs 6 de la plateforme, l’état actualisé des applications logicielles s’exécutant localement.

[0082] Dans le cas présent, en fonction par exemple de l’état des applications logicielles déterminés à l’étape 201 b et/ou de l’état des ressources déterminé à étape 201 a, le contrôleur 8 de la plateforme 20_1 détermine que l’exécution de l’application hébergée APPJ3 présente un dysfonctionnement. Typiquement, cela fait suite à la détection d’un crash logiciel, de la disparition d’une ressource ou de l’éloignement temporaire de la plateforme sur laquelle s’exécutait une application avec laquelle l’application APP_B échangeait des données lors de son exécution etc.

[0083] Dans une étape 202a, le contrôleur 8 de chaque plateforme transmet l’état actualisé de disponibilité des ressources, également à la fréquence Tr (sur la liaison 6i depuis la plateforme 20J, i= 1 à 3) à l’orchestrateur 10, qui le reçoit.

[0084] En parallèle, dans une étape 202b, l’orchestrateur 10 reçoit, par exemple à la fréquence Tt, les conditions courantes de transport sur les liaisons 40, 41 , 51 , 52 et 53.

[0085] En parallèle, dans une étape 202c, le contrôleur 8 de la plateforme 20_1 transmet au bloc d’ordonnancement 11 de l’orchestrateur 10 un état indiquant que l’hébergement de l’application APPJ3 est à réaffecter.

[0086] Le bloc d’ordonnancement 11 de l’orchestrateur 10, extrait de la base de données 13 les informations associées à l’application APPJ3 et indiquées (ou certaines d’entre elles) aux items a, b, c plus haut, puis il effectue une demande de re-sélection de ressources pour héberger l’application APPJ3 au bloc de sélection 12 de l’orchestrateur 10, dans une étape 203. [0087] Le bloc de sélection 12, dans une étape 204, sélectionne celle des plateformes 20_1 , 20_2, 20_3, dont les ressource(s) de traitement seront affectées à l’exécution de I’ application logicielle APP_N, cette sélection étant effectuée en fonction d’au moins les critères indiqués relativement à l’étape 105 de la figure 2 ; puis le bloc de sélection 12 indique la plateforme sélectionnée (voire dans un mode de réalisation les ressources sélectionnées de cette plateforme sélectionnée, quand ce n’est pas le contrôleur local 8 de la plateforme sélectionnée qui sélectionne les ressources affectées) au bloc d’ordonnancement 11 , dans le cas présent la plateforme 20_2.

[0088] Dans une étape 205, le bloc d’ordonnancement 11 transmet une demande d’hébergement de l’application APPJ3 au contrôleur local 8 de la plateforme 20_2 et fournit les informations de contexte (ou les informations permettant le téléchargement du contexte). Dans le cas présent, les informations sont à téléchargées depuis la plateforme 20_1 d’hébergement antérieur de l’application APP_B ou depuis un NAS, par exemple la base 50.

[0089] Dans une étape 206, en réponse à la réception de cette demande de redéploiement, le contrôleur 8 de la plateforme 20_2 effectue le déploiement de l’application, et envoie ensuite un état de bonne exécution de l’application APP_B après son déploiement, confirmant qu’il s’est effectué correctement, le cas échéant (état au contenu similaire à celui envoyé à l’étape 102c ou 202c).

[0090] L’application APPJ3 dans son exécution, met en oeuvre des échanges sur une ou plusieurs des liaisons, parmi les liaisons 40, 41 , 52 connectant la plateforme 20_2 hébergeant APPJ3 à son environnement immédiat.

[0091] Comme évoqué précédemment, dans un mode de réalisation, des ressources de transport sont réservées pour ces échanges.

[0092] Dans un mode de réalisation, le bloc de sélection 11 dans le cadre du redéploiement logicielle à héberger sélectionne la plateforme dans laquelle redéployer l’application APP_B en évaluant en outre si des données de contexte et/ou le temps d’instanciation sont bien compatibles d’une durée maximum allouée au déploiement de l’application logicielle (cette durée étant indiquée dans la requête initiale REQ associée à APPJ3) et/ou sont compatibles des exigences de déploiement comme décrit en référence à la figure 2. [0093] On notera que le dysfonctionnement d’une application dans un mode de réalisation est identifié directement par l’orchestrateur 10 (et non suite à un message du contrôleur local), qui met alors en oeuvre les étapes 203 et suivantes.

[0094] Dans le mode de réalisation considéré, les codes des applications à héberger sont déjà résidents (de façon non active, i.e. sans exécution) sur chaque plateforme. Si ce n’était pas le cas pour certaines des applications, un critère supplémentaire de sélection de plateforme pourra être considéré : la présence du code de l’application sur les plateformes.

[0095] Une mesure supplémentaire qui permet de limiter l’usage des ressources de transmission sans fil consiste à modifier l’algorithme de sélection de l’orchestrateur 10 pour associer au déploiement d’une application logicielle tout ou partie des applications « support » qui sont nécessaires au bon fonctionnement de l’application à déployer et ainsi maintenir le maximum d’interactions colocalisées, réduisant ainsi le besoin d’échanges de la plateforme avec les autres plateformes. Pour ce faire, un arbre d’inter-dépendances des applications est maintenu sous la forme par exemple d’une définition de chorégraphie avec comme point de départ les applications à déployer. L’algorithme de sélection peut alors parcourir l’arbre de chorégraphie et consolider le besoin en ressources de calcul et mémoire et transmission pour chaque application rencontrée dans l’arbre. On notera que contrairement aux ressources de calcul et ressources mémoire qui sont additives (déployer un service support augmente le besoin de calcul et de mémoire), les ressources de transmission peuvent varier à la hausse ou à la baisse (les échanges colocalisés viennent réduire le besoin en ressources de transmission). Il y a donc un compromis à faire. La sélection de la ressource matérielle pour héberger les applications devient alors une recherche classique de solution optimale dans un champ de contraintes données d’une part par les ressources disponibles et d’autre part par les besoins en ressources.

[0096] Par exemple, dans un mode de réalisation, on représente les applications par une structure arborescente, dans laquelle deux applications logicielles sont reliées par une branche de la structure (représentant leurs échanges) si elles mettent en oeuvre entre elles des télécommunications lors de leur exécution. Les noeuds de l’arbre représentent les applications logicielles et portent les méta-données desdites applications logicielles (calcul, mémoire, gabarits de transport). Les branches de l’arbre portent les gabarits de transport spécifiques des échanges inter-nœuds. Au fur et à mesure qu’on parcourt l’arbre, on additionne les besoins de calcul, de mémoire et d’échanges donnés par les nœuds et on soustrait les besoins d’échanges donnés par les branches.

[0097] Les deux applications liées par une branche sont par exemple une application de capture d’images par un Radar chargé de poursuivre une cible et une application de calcul de trajectoire de l’avion transportant le Radar (et devant donc poursuivre la cible).

[0098] On notera qu’au moins les deux situations suivantes peuvent se produire :

[0099] - l’application logicielle est lancé depuis une market place ou équivalent ; l’initiateur de la requête REQ sera alors l’interlocuteur de l’application à héberger et est donc défini par l’adresse source de la requête REQ ; il s’agit d’un mode push : l’application sait à qui envoyer ses données ;

[0100]- l’application logicielle est lancée automatiquement au profit d’un groupe de participants, pas forcément tous connectés au réseau à ce moment-là ; dans ce cas, le choix de la plateforme d’hébergement pourra se faire en comparant les ressources de transmission des plateformes avec les modes de fonctionnement exprimés pour l’application dans les gabarits de transport ; il s’agit alors d’un mode pull : l’application attend qu’un interlocuteur se manifeste pour lui envoyer ses données et ce n’est qu’à ce moment-là que le chemin bout-en-bout est pris en compte et que le mode de fonctionnement effectif est choisi.

[0101] Ainsi l’invention propose un orchestrateur de cloud qui, évalue l’adéquation d’un serveur pour héberger une application en fonction de la ressource CPU disponible et/ou de la quantité de mémoire disponible versus les besoins de l’application en CPU et/ou mémoire, et qui évalue en outre cette adéquation en fonction des caractéristiques du réseau de bout en bout versus les besoins d’échange préalablement évalués des applications logicielles (de manière que les caractéristiques des liaisons de transmission mises en œuvre pour assurer les échanges lors de l’exécution de l’application logicielle sur le serveur sélectionné remplissent ces besoins d’échanges). Un orchestrateur implémentant l’invention peut être utilisé dans des réseaux contraints avec un niveau de performance satisfaisant. L’hétérogénéité des capacités de transmission et l’état de discrétion contribuent aux conditions de transport. La prise en compte de ces informations est réalisée par la sélection d’un gabarit de transport compatible des conditions de transport constatées.

[0102] L’invention permet aussi dans un mode de réalisation de prendre en compte le temps de déploiement des logiciels ou composants dans la sélection des ressources d’hébergement, pour garantir une mise à disposition dans les délais attendus.

[0103] Ainsi l’invention peut être mise en oeuvre dans les orchestrateurs existants en complétant leur mécanisme de scoring calculé pour chaque ressource de traitement disponible ou inversement en ne calculant ce scoring que pour les ressources compatibles (en termes de liaisons impliquées) des conditions de transport minimales.

[0104] Le procédé peut être mis en oeuvre par l’exécution d’instructions logicielles sur un processeur, comme décrit ci-dessus. Alternativement, il peut être mis en oeuvre par un hardware dédié, typiquement un circuit intégré numérique, soit spécifique (ASIC) ou basé sur une logique programmable (par exemple FPGA/Field Programmable Gate Array).