FR3039024A1 - Systeme et procede automatique de deploiement des services sur un noeud reseau - Google Patents

Systeme et procede automatique de deploiement des services sur un noeud reseau Download PDF

Info

Publication number
FR3039024A1
FR3039024A1 FR1501505A FR1501505A FR3039024A1 FR 3039024 A1 FR3039024 A1 FR 3039024A1 FR 1501505 A FR1501505 A FR 1501505A FR 1501505 A FR1501505 A FR 1501505A FR 3039024 A1 FR3039024 A1 FR 3039024A1
Authority
FR
France
Prior art keywords
node
service
leader
orchestrator
master
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1501505A
Other languages
English (en)
Other versions
FR3039024B1 (fr
Inventor
Jean Emmanuel Orfevre
Alexandre Orfevre
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Rizze SAS
Original Assignee
Rizze SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rizze SAS filed Critical Rizze SAS
Priority to FR1501505A priority Critical patent/FR3039024B1/fr
Priority to BR102015025779A priority patent/BR102015025779A2/pt
Publication of FR3039024A1 publication Critical patent/FR3039024A1/fr
Application granted granted Critical
Publication of FR3039024B1 publication Critical patent/FR3039024B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/14—Routing performance; Theoretical aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G06F9/5088—Techniques for rebalancing the load in a distributed system involving task migration

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne un système et un procédé automatique de déploiement de service sur un nœud réseau. Le système comprend au moins une base de registres et au moins un système d'exploitation composé d'au moins un nœud maître et au moins un nœud esclave. La base de registres est composée de plusieurs registres publics et/ou privées et/ou des registres répliqués. Chaque nœud maître et/ou esclave, qu'il soit virtualisé sur une plate-forme en nuage, communément appelé cloud, ou en infrastructure locale, comporte: un répartiteur de charges et un service découverte. Le nœud maître comporte, en plus, un orchestrateur et un référentiel.

Description

La présente invention concerne le domaine technique de la répartition de charges, de la gestion de nœuds et de la gestion de services.
Dans l’état de la technique, différentes méthodes sont mises en œuvre afin d’optimiser les résultats des divers requêtes réalisées par les utilisateurs. Une de ces méthodes est la répartition de charges (load balancing) de requêtes sur un service.
Le load balancing est connu pour être une méthode de distribution de la charge de travail sur un certain nombre de dispositifs et/ou serveurs pour augmenter la productivité. Cette répartition de charge peut être avec état (statefull), donc possible de suivre et de stocker les sessions des utilisateurs en cours un protocole, une donnée, un paramètre, ou sans état (stateless), qui, de son côté, fournit une réponse après une requête sans stocker d’informations de session, ce qui permet une plus simple élasticité du service (scalabilité).
Pour rendre le load balancing performant, des solutions pour rassembler les nœuds, physiques comme basés sur un système d’exploitation, sous un cluster ou une ferme de nœud ont été présentées. Cependant ces solutions ne proposent pas des moyens efficaces pour résoudre le problème de scalabilité des nœuds et des services. En effet, il n’a pas encore été décrit des moyens automatiques de gestion du cycle de vie des nœuds dans une ferme de nœuds dans l’objectif de rendre ces services disponibles, stables et robustes dans des environnements réseaux, considérés aujourd’hui très instables sur internet.
Aussi, plusieurs erreurs peuvent survenir lors de la mise en œuvre des méthodes précédemment mentionnées. Il ne faut pas considérer les pannes des réseaux informatique comment étant très rares pour construire un système fiable. Il faut prendre en considération ces pannes et savoir qu’elles font partie des réseaux informatique. Les pannes qui doivent être gérées sont: la disparition d’un service; la disparition d’un nœud, l'arrêt d’un nœud, la panne d’un service, la disparition d’un ensemble de nœud, cette liste n’étant pas exhaustive.
De plus, dans l’état actuel, l’usage des registres de services publics n’assurent pas la confidentialité des services, étant donné qu’ils sont sauvegardés sur des bases de registres. Ce qui rend les code source des services potentiellement vulnérables en matière de copies, d’attaques ou d’analyse.
Il est donc nécessaire de créer un procédé pour gérer automatiquement le déploiement d’un services à au moins un nœud basé sur un système d’exploitation, en tenant compte des requêtes réalisées par au moins un utilisateur, mais aussi les possibles défaillances, erreurs et échecs qui peuvent provenir des nœuds et des services.
Glossaire:
Le terme “répartiteur de charge” utilisé dans la présente invention peut être compris de façon non limitative comme “équilibreur de charge”, “load balancer”, “dispositif de partage de charges”, “dispositif de division de flux de réseau”.
Le terme “nœud” utilisé dans la présente invention peut être compris de façon non limitative comme “serveur virtuel, sur internet”, “serveur virtuel, sur cloud”, “serveur virtuel, sur une plate-forme en nuage”, “serveur sur une infrastructure locale”, “nœud de type maître”, “nœud de type esclave”, “réseaux de serveurs”, “cluster”, “ferme de serveurs”, “ferme de nœuds”.
Le terme “requête” désigne un ordre d'exécution, il suit un protocole de communication et possède des paramètres en entrée (question), un statut de la réponse et un retour (réponse). Souvent sur les réseaux TCP, INPROC, IPC, UDP ou PGM, une requête dans le protocole choisi par le client et un retour OK ou ERROR dans un format lié au protocole.
Le terme “registre de service” ou “base de registre”, désigne un service dans lequel est conservé les conteneurs et les configurations des autres services. Le registre de service contient l’ensemble des services et leurs versions. Il est configuré pour permettre le téléchargement d’un service dans une version. L’accès au registre de service se déroule avec authentification ou sans authentification. Dans le cas où il se déroule sans authentification, nous le désignons “registre public”, ce registre est vulnérable et non sécurisé.
Le terme “conteneur image de service” représente le logiciel enfermé dans un conteneur et qui une fois téléchargé depuis le registre de service, installé et exécuté permet d'exécuter un service sur un nœud. Il est caractérisé par un programme, un nom, une version et une date de construction.
Le terme “système d’exploitation” utilisé dans la présente invention peut être compris de façon non limitative comme “operating System”, “Datacenter”, “operating System de ferme de nœud” et/ou un ensemble de nœud (ferme de nœud) répondant à des principes déterminés et ayant au moins un maître et de zéro à plusieurs esclaves. Le système d’exploitation, sur sa forme minimale peut ainsi être constitué uniquement d’un nœud. Et il peut aussi être constitué de multiples nœuds.
Le terme “identifiant unique de ressource” désigne le nom d’un nœud et son identification. En TCP/IP l’identifiant unique est appelé URL Le système d’exploitation, selon l’invention, fonctionne avec d’autre protocoles réseau, comme INPROC, IPC, UDP ou PGM, aussi l’identifiant unique de ressource peut prendre d’autres formes non encore connues à ce jour.
Le terme “référentiel” utilisé dans la présente invention peut être compris de façon non limitative comme “service centralisé pour maintenir des informations de configuration, de nommage, assurer la synchronisation distribuée, et fournir des services de groupe”, “logiciel de gestion de configuration pour systèmes distribués”, “système de gestion de nœuds redondants”.
Le “service” est un programme installé sur un ou plusieurs nœuds et exécuté à la demande (“requête”) d’un client sur un nœud maître et/ou esclave.
Le terme “orchestrateur” utilisé dans la présente invention peut être compris de façon non limitative comme “module d'orchestration de services de réseau”, “système d'orchestration de contenu”, “processus automatique d'organisation, de coordination, et de gestion de systèmes informatiques complexes”, “orchestration de la gestion de services”.
Le terme “service découverte” utilisé dans la présente invention peut être compris de façon non limitative comme un service qui contrôle les conteneurs image de service exécuté par un orchestrateur sur une machine et transmet leurs adresses à l'ensemble des nœuds.
Description de l’invention:
La présente invention concerne un système et un procédé automatique de déploiement de service sur un nœud réseau. Le système comprend au moins une base de registres et au moins un système d’exploitation composé d’au moins un nœud maître et au moins un nœud esclave. La base de registres est composée de plusieurs registres publics et/ou privées et/ou des registres répliqués. Chaque nœud maître et/ou esclave, qu’il soit virtualisé sur une plate-forme en nuage, communément appelé cloud, ou en infrastructure locale, comporte: un répartiteur de charges et un service découverte. Le nœud maître comporte, en plus, un orchestrateur et un référentiel.
Chaque nœud peut accéder aux registres privés par l'intermédiaire de protocoles de communication et de sécurité, préférentiellement TCP, INPROC, IPC, UDP ou PGM ou autres.
Chaque nœud (qu’il soit virtuels ou non) possède : des ressources physiques ou virtuelles rattachées, une ou plusieurs unités de calcul (CPU), une ou plusieurs mémoires vive non persistante (RAM), et une ou plusieurs unité de stockage persistante ou toute autre type de ressources.
Aussi, chaque nœud est identifié par un nom unique sur son protocole: à titre d’exemple, sur le protocole IP, il sera utilisé l’adresse IP interne à la ferme de ce nœud.
Les dessins annexés illustrent l’invention:
La figure 1 représente le système composé d’une à plusieurs bases de registres (2), publique et/ou privée, hébergeant au moins un conteneur contenant des images de service (3), pour chaque service proposé, et aussi composé d’au moins un système d’exploitation (1) composé d’au moins un nœud maître (4) et d’au moins un nœud esclave (9) ayant chacun un répartiteur de charges (5), un service découverte (8) et des moyens pour déployer des services (10). Les nœuds maîtres (4) comportant, en plus, un référentiel (6) et un orchestrateur (7).
La figure 2 représente un orchestrateur leader (11) basé sur un nœud maître leader (12).
La figure 3 représente l’orchestrateur leader (11) basé sur un nœud maître (4) quelconque.
La figure 4 représente la réplication de la base de registres (2), publique et/ou privée, sur une autre base de registres, publique et/ou privée, et/ou la réplication de la base de registres (2), publique et/ou privée, sur un fournisseur ou une infrastructure en nuage (13).
La figure 5 représente l'exécution d’une requête pour démarrer un service (10) donné vers un nœud esclave (9) placé sur le système d’exploitation (1), respectant des règles de service configurées qui organisent les nœuds (9) et/ou les services (10) selon un ordre déterminé et respectant l’indication d’un orchestrateur leader (11) sur des ressources disponibles et nécessaires pour déployer le service (10) demandé.
La figure 6 représente la confirmation par un service découverte (8) du nœud esclave (9), à qui a été dirigée la requête, qu’un tel nœud esclave (9) ne possède pas la version de l’image nécessaire pour déployer le service (10) demandé. Elle représente aussi l’interrogation de la base de registres (2) par le service découverte (8) du dit nœud (9), paramétré préalablement avec le protocole de communication adéquat, préférentiellement TCP, INPROC, IPC, UDP ou PGM, pour accéder à au moins une image de service (3). Le conteneur contenant des images de service (3) est archivé dans la dite base (2). Il sera téléchargé la version de l’image nécessaire pour déployer le service (10) demandé sur le nœud cible de l'installation.
La figure 7.a représente l’initiation du processus de téléchargement de l’image et la figure 7.b représente l’ajout d’un nouveau service (10) au dit nœud (9), suivi par le démarrage du service (10) demandé par le dit nœud esclave (9).
La figure 8 représente la requête dirigée vers le deuxième nœud esclave (9) respectant l’ordre configuré, quand l’orchestrateur leader (11) indique que le premier nœud esclave (9) ne possède pas de ressources disponibles et nécessaires pour déployer le service (10) demandé.
En référence à ces dessins, le système comporte des moyens adaptés pour la mise en œuvre du procédé automatique de déploiement de service sur un nœud réseau caractérisé en ce qu’il comporte : a) d’une à plusieurs bases de registres, publiques et/ou privées (2), périodiquement répliquées, sur un fournisseur ou une infrastructure en nuage (13) ou sur une autre base de registres, publique et/ou privée, et hébergeant au moins un conteneur contenant des images de service (3) pour chaque service proposé, b) au moins un système d’exploitation (1) composé d’au moins un nœud maître (4) et au moins un nœud esclave (9) comportant chacun un répartiteur de charges (5), un service découverte (8), un protocole d’authentification nécessaire pour accéder à la ou les bases de registres (2), en mode privées et/ou des moyens pour déployer des services (10), dont le nœud maître (4) comporte, en plus, un orchestrateur (7) et un référentiel (6).
Le procédé automatique de déploiement de service (10) sur un nœud réseau est caractérisé en ce qu’il comporte les étapes suivantes: A partir d’une configuration faite par un utilisateur, le procédé automatique de déploiement réalise une demande de démarrage de service (“requête”) pour démarrer un service (10). La soumissions de cette requête de démarrage de service peut être réalisée de plusieurs manière différente et suivant plusieurs protocoles de type réseau, préférentiellement TCP, INPROC, IPC, UDP ou PGM, ou en accès direct sur le système d’exploitation par exécution en ligne de commande, ou par connections au système d’exploitation via prise en main à distance par exemple ou autre procédés identiques. L’administrateur du système peut également réaliser des requêtes pour démarrer certain services ou pour les mettre à jour.
Dans une réalisation, l’utilisateur accède librement aux services (10), dans une autre réalisation, l’accès aux services (10) est conditionné à une authentification au préalable. Un ou plusieurs utilisateurs peuvent réaliser des requêtes en même temps et/ou le même utilisateur peut enchaîner plusieurs requêtes.
Parallèlement aux requêtes réalisées par l’utilisateur, des services (10) peuvent également réaliser des requêtes sur d’autres services (10) et ainsi devenir client d’autres services.
La requête est donc dirigée vers le répartiteur de charges (5) qui ensuite la transmet à un nœud esclave (9) placé sur le système d’exploitation (1). Chaque nœud est composé d’un répartiteur de charges (5), un service découvert (8), un protocole d’authentification nécessaire pour accéder à la ou les bases de registres (2), en mode privées et/ou des moyens pour déployer des services (10). Les nœuds maîtres (4) comportent, en plus, un référentiel (6) et un orchestrateur (7).
De préférence, sur chaque système d’exploitation (1), un nœud maître (12) et un orchestrateur (11) sont élus leader du système.
De préférence, sur chaque système d’exploitation (1), un nœud maître (4) est connecté avec un nœud esclave (9), à qui il délègue les services. Un nœud maître (4) peut également contenir un nœud esclave (9) (embouti et intégré) et exécuter les mêmes services (10) qu’un nœud esclave (9).
Idéalement, lors d’une défaillance quelconque du nœud maître leader (12), il est possible de le remplacer automatiquement par un autre nœud maître (4), qui devient ensuite le nouveau nœud maître leader (12). Aussi, lors d’une défaillance quelconque de l’orchestrateur leader (11), il est possible de le remplacer automatiquement par un autre orchestrateur (7), qui devient ensuite l’orchestrateur leader (11).
Dans une réalisation, l’orchestrateur leader (11) est basé sur le nœud maître leader (12), dans une autre réalisation, l’orchestrateur leader (11) et le nœud maître leader (12) ne partagent pas la même structure, ainsi, il est possible que le nœud maître leader (12) héberge l’orchestrateur leader (11), qui, à son tour, est basé sur un nœud maître (4) quelconque.
Une fois que la requête de l’utilisateur et/ou du service (10) est dirigée vers au moins un nœud placé sur le système d’exploitation (1), la requête est dirigée vers le nœud esclave (9), en fonction des règles de service configurées par l’administrateur du système d’exploitation (1), pour démarrer le service (10) souhaité.
Commodément, les règles de service sont définies dans une configuration (fichier ou autre). Préférentiellement, ces règles organisent les nœuds (9) et/ou les services (10) selon un ordre déterminé. Pour répartir la charge d’utilisation de services entre plusieurs nœuds, il est possible de choisir de diriger la requête vers un nœud (9) pris aléatoirement respectant l’ordre configuré, par exemple, ou vers le nœud (9) le moins utilisé déterminé par un calcul de l’historique ou un nœud (9) dans l’ordre séquentiel de la liste ou le nœud (9) ayant le plus de ressource disponible pour exécuter un service. Il est également possible, les combinaisons d’une ou plusieurs de ces techniques.
Parallèlement, l’orchestrateur leader (11) met en place plusieurs tâches: il réalise une recherche sur l’ensemble des nœuds maîtres (4) et/ou esclaves (9) pour indiquer les instances de services, les ressources disponibles et les ressources nécessaires pour déployer le service (10) demandé. L’orchestrateur leader (11) indique également la version de l’image nécessaire pour déployer le service (10) demandé dans sa requête vers le registre.
Avantageusement les informations sur les ressources nécessaires pour déployer le service (10) demandé sont préalablement fournis et/ou configurées par l’administrateur du système.
Dans une réalisation, selon les schémas représentés par les figures, mais de façon non limitative, la requête est dirigée vers le premier nœud esclave (9) respectant l’ordre configuré, une fois que l’orchestrateur leader (11) ait indiqué qu’un tel nœud (9) possédait des ressources disponibles et nécessaires pour déployer le service (10) demandé. Le service découvert (8) qui compose le dit nœud (9) confirme donc à l’orchestrateur leader (11) qu’un tel nœud (9) possède la version de l’image nécessaire pour déployer le service (10) demandé. Ensuite, l’orchestrateur leader (11) orchestre qu’un tel nœud (9) démarre ledit service (10) et l’utilisateur reçoit la réponse à sa requête. L’utilisateur du service ne voit pas cette mécanique qui est réalisée par le système d’exploitation (1).
Dans une autre réalisation, aussi selon les schémas représentés par les figures, mais de façon non limitative, la requête est dirigée vers le premier nœud esclave (9) respectant l’ordre configuré, mais l’orchestrateur leader (11) indique qu’un tel nœud (9) ne possède pas de ressources disponibles et nécessaires pour déployer le service (10) demandé. Ainsi, l’orchestrateur leader (11) demande que la requête soit dirigée vers le deuxième service (10) respectant l’ordre configuré et/ou dirigé vers le deuxième nœud esclave (9) respectant l’ordre configuré. Ensuite, le service (10) est démarré et l’utilisateur reçoit la réponse à sa requête.
Encore dans une autre réalisation, selon les schémas représentés par les figures, mais de façon non limitative, la requête est dirigée vers le premier nœud esclave (9) respectant l’ordre configuré, une fois l’orchestrateur leader (11) indiqué qu’un tel nœud (9) possède des ressources disponibles et nécessaires pour déployer le service (10) demandé. Ensuite, l’orchestrateur leader (11) demande à un nœud esclave (9) de démarrer ledit service (10). Cependant, le service découvert (8) qui compose le dit nœud (9) informe à l’orchestrateur leader (11) qu’un tel nœud (9) ne possède pas la version de l’image nécessaire pour déployer le service (10) demandé. L’orchestrateur leader (11) ordonne donc l'interrogation de la base de registres (2), privée et/ou publique, afin que soit téléchargé sur ledit nœud (9) la version de l’image nécessaire pour déployer le service (10) demandé.
Commodément, l’orchestrateur leader (11) ordonne l'interrogation de la base de registres (2) publique et/ou privé pour télécharger intégralement l’image nécessaire pour déployer le service (10) demandé ou pour télécharger seulement la partie correspondant à la dernière version mise à jour par l’administrateur du système de l’image nécessaire pour déployer le service (10) demandé. Un tel téléchargement partiel des différences s’appelle le téléchargement différentiel.
De préférence, le système est composé d’une à plusieurs bases de registres (2) privées et/ou publiques, périodiquement répliquées, sur un fournisseur ou une infrastructure en nuage (13) ou sur une autre base de registres (2), publique et/ou privée, et hébergeant au moins un conteneur contenant des images de service (3) pour chaque service proposé. L’accès du nœud à cette base de registre (2) en mode privé est conditionné à un protocole de communication et de sécurité, préférentiellement TCP, INPROC, IPC, UDP ou PGM.
Idéalement, le et/ou les nœuds maîtres (4) et/ou esclaves (9) sont paramétrés préalablement par l’administrateur du système avec un protocole de communication et de sécurité, préférentiellement TCP, INPROC, IPC, UDP ou PGM, nécessaire pour accéder à la et/ou les bases de registre (2), en mode privé. Ainsi, seulement les nœuds (4 - 9) ayant été paramétrés préalablement par l’administrateur du système peuvent accéder à au moins une image de service (3) hébergé dans la base de registres (2), en mode privé.
Avantageusement, l’administrateur du système a également accès à la et/ou aux bases de registres (2) publiques et/ou privées, ce qui lui permet de gérer les conteneurs contenant des images de service (3). L’administrateur du système a donc les moyens de créer, réorganiser et supprimer, à son gré, les conteneurs contenant des images de service (3).
Ainsi, selon les schémas représentés par les figures, mais de façon non limitative, lorsque l’orchestrateur leader (11) orchestre l’interrogation de la base de registres (2) en mode privé pour télécharger sur le dit nœud esclave (9) la version de l’image nécessaire pour déployer le service (10) demandé, le protocole de communication et de sécurité, préférentiellement TCP, INPROC, IPC, UDP ou PGM, est demandé. Une fois authentifié, le nœud (9) à accès au conteneur des images de service (3) du service (10) demandé, le processus de téléchargement de l’image s’initie et un nouveau service (10) est désormais ajouté au nœud (9).
Ensuite, l’orchestrateur leader (11) ordonne au nœud (9) de démarrer le dit service (10) afin de fournir à l’utilisateur le service demandé et une réponse à sa requête.
Idéalement, étant donné que chaque nœud maître (4) et/ou esclave (9) possède un répartiteur de charges (5) et un service découverte (8) et le nœud maître (4) possède en plus un orchestrateur (7) et un référentiel (6), lorsqu’un service (10) est ajouté sur un nœud esclave (9), le service découverte (8) de ce nœud (9) met à jour son répartiteur de charge (5) et informe l’orchestrateur leader (11) sur cet ajout de plusieurs manières différentes, par exemple, par requête dirigée (TCP, INPROC, IPC, UDP ou PGM) ou requête diffusé (broadcast) TCP/UDP, cette liste n’étant pas exhaustive.
Une fois que l’orchestrateur leader (11) a reçu la demande de mise à jour, il met à jour le référentiel (6) qui compose le nœud maître leader (12). Automatiquement l’information est transmise aux autres référentiels (6) de chacun des autres nœuds maîtres (4).
Parallèlement, les services découverts (8) de chaque nœud, maître (4) et/ou esclave (9), réalisent périodiquement des vérifications sur ses propres nœuds (4 - 9) en tenant compte de la configuration des référentiels (6) du nœud maître leader (12) et des autres nœuds maîtres (4).
La périodicité de la réalisation de la vérification par les services découverts (8) sur ses propres nœuds (4-9) est paramétrable par l’administrateur du système.
Dans une réalisation, le service découverte (8) d’un nœud esclave (9) vérifie si son nœud esclave (9) à les mêmes configurations que le référentiel (6) du nœud maître (4) auquel il est connecté. Dans une autre réalisation, le service découvert (8) d’un nœud maître (4) vérifie si son nœud (4) a les mêmes configurations que le référentiel (6) du nœud maître leader (12).
Préférentiellement, lorsque les services découverts (8) de chaque nœud, maître (4) et/ou esclave (9), vérifient que ses nœuds (4 - 9) n’ont pas les mêmes configurations qu’aux référentiels (6), automatiquement les dits services découvertes (8) mettent à jour les répartiteurs de charge respectifs.
Avantageusement, un même service peut être mis à disposition, c'est à dire, exécuté sur le système d’exploitation (1), en une ou plusieurs versions en même temps.
Idéalement, les répartiteurs de charge (5) et les référentiels (6) doivent avoir les mêmes configurations. Les mêmes informations sur les services (10). Cette synchronisation permet d’actualiser automatiquement les règles de service configurées par l’administrateur du système, qui à leur tour sont définies dans un fichier de configuration. Ces règles organisent les nœuds (4 - 9) et/ou les services (10) selon un ordre déterminé et permettent de diriger la requête vers le service (10) souhaité par l’utilisateur, lorsqu’il saisit sa demande par sa soumission au système d’exploitation, ou demandé par un autre service (10), lorsqu’il réalise une requête pour démarrer d’autres services (10).
Les vérifications réalisées par les services découvertes (8) de chaque nœud, maître (4) et/ou esclave (9), sur ses propres nœuds (4 - 9) permettent également à l’orchestrateur leader (11) de réaliser des contrôles de performance et/ou de contrôle d’état sur les nœuds (4 - 9) et/ou services (10).
Dans une réalisation, le résultat du contrôle de performance et/ou du contrôle d’état indique le bon fonctionnement du nœud (9) et/ou du service (10), lorsque l’orchestrateur leader (11) demande à un nœud esclave (9) de démarrer un service (10) et/ou réalise une recherche sur l’ensemble des nœuds (9) pour connaître les instances de services et les ressources disponibles, et il reçoit les retours des services découvertes (8) de chaque nœud esclave (9).
Dans une autre réalisation, le résultat du contrôle d’état indique le dysfonctionnement d’un nœud (9) et/ou d’un service (10), lors d’une défaillance quelconque, notamment une faille de communication, entre l’orchestrateur leader (11) et un service découverte (8) déterminé.
Comme réaction au dysfonctionnement du nœud (9) et/ou service (10), l’orchestrateur leader (11) demande que la requête soit dirigée vers le prochain service (10) respectant l’ordre configuré et/ou dirigé vers le prochain nœud (9) respectant l’ordre configuré. Aussi, comme réaction au dysfonctionnement du service (10), l’orchestrateur leader (11) met à jour le référentiel (6) qui compose le nœud maître leader (12) et automatiquement l’information est répliquée aux référentiels (6) de chacun des autres nœuds maîtres (4).
Parallèlement, les services découvertes (8) de chaque nœud, maître (4) et/ou esclave (9), mettent à jour automatiquement les répartiteurs de charge (5) respectifs. Désormais, les requêtes ne seront plus dirigées vers ce nœud (9) et/ou service (10).
Ainsi, le système et le procédé selon l’inventions sont particulièrement destinés au déploiement automatique d’un service (10) sur un nœud réseau, en tenant compte aussi des possibles défaillances, erreurs et échecs qui peuvent provenir des nœuds et des services (10).

Claims (10)

  1. Revendications:
    1. Procédé automatique de déploiement de service sur un nœud réseau caractérisé en ce qu’il comporte les étapes suivantes: a. Exécution d’une requête pour démarrer un service (10) donné vers un nœud esclave (9) placé sur le système d’exploitation (1): i. respectant des règles de service configurées par l’administrateur du système, qui organisent les nœuds (9) et/ou les services (10) selon un ordre déterminé, ii. et respectant l’indication d’un orchestrateur leader (11) sur des ressources disponibles et nécessaires pour déployer le service (10) demandé. b. Confirmation par un service découverte (8) du nœud esclave (9), à qui a été dirigé la requête, si un tel nœud esclave (9) possède ou non la version de l’image nécessaire pour déployer le service (10) demandé. c. Interrogation d’une base de registres (2) privée ou publique par le service découverte (8) du dit nœud esclave (9), en utilisant un protocole de communication et de sécurité, préférentiellement TCP, INPROC, IPC, UDP ou PGM, permettant d’accéder à au moins une image de service (3) hébergé dans la dite base (2), pour télécharger la version de l’image nécessaire pour déployer le service (10) demandé, quand ledit nœud esclave (9) ne la possède pas. d. Initiation du processus de téléchargement de l’image et ajout d’un nouveau service (10) au dit nœud esclave (9). e. Démarrage du service (10) demandé par le dit nœud esclave (9).
  2. 2. Procédé selon la revendication 1, caractérisé en ce que les requêtes sont réalisées par des utilisateurs en saisissant une demande par sa soumission au système d’exploitation (1) et/ou par des services (10) pour démarrer d’autres services (10) et/ou par un administrateur pour démarrer certain services ou les mettre à jour.
  3. 3. Procédé selon les revendications 1 et 2, caractérisé en ce que la soumission de la requête de démarrage de service peut suivre des protocoles de type réseau, préférentiellement TCP, INPROC, IPC ou PGM, UDP ou être en accès direct sur le système d’exploitation (1) par exécution en ligne de commande, ou par connections au système d’exploitation (1) via prise en main à distance.
  4. 4. Procédé selon la revendication 1, caractérisé par un choix de diriger la requête vers un nœud (9) pris aléatoirement dans la liste ou vers le nœud (9) le moins utilisé déterminé par un calcul de l'historique ou un nœud (9) dans l’ordre séquentiel de la liste.
  5. 5. Procédé selon la revendication 1, caractérisé en ce qu’il comprend les étapes suivantes: a. lorsqu’un service (10) est ajouté sur un nœud esclave (9), le service découvert (8) de ce nœud (9) met à jour son répartiteur de charge (5) et informe l’orchestrateur leader (11) sur cet ajout, b. l’orchestrateur leader (11) met à jour un référentiel (6) qui compose un nœud maître leader (12). c. automatiquement l’information est répliquée aux référentiels (6) de chacun des autres nœuds maîtres (4).
  6. 6. Procédé selon les revendications 1 et 5, caractérisé en ce qu’il comprend les étapes suivantes: a. vérification par le service découverte (8) d’un nœud esclave (9) si son nœud à les mêmes configurations qui le référentiel (6) du nœud maître (4) auquel il est connecté. b. vérification par le service découverte (8) d’un nœud maître (4) si son nœud (4) à les mêmes configurations que le référentiel (6) du nœud maître leader (12). c. Mise à jour automatique par les dits services découvertes (6) de ses répartiteurs de charge (5) respectifs, si ses nœuds n’ont pas les mêmes configurations que les référentiels (6).
  7. 7. Procédé selon les revendications 1 et 6, caractérisé en ce qu’il comprend les étapes suivantes: a. Réalisation de contrôle de performance et/ou d’état sur les nœuds (9) et/ou service par l’orchestrateur leader (11), lorsqu’il ordonne qu’un nœud (9) démarre un service (10) et/ou réalise une recherche sur l’ensemble des nœuds (9) pour connaître les instances de services et les ressources disponibles b. Direction de la requête vers le prochain service (10) respectant l’ordre configuré et/ou dirigé vers le prochain nœud (9) respectant l’ordre configuré par l’orchestrateur leader (11), lors d’une défaillance de communication entre l’orchestrateur leader (11) et un service découverte (8) déterminé c. Mise à jour du référentiel (6) qui compose le nœud maître leader (12) par l’orchestrateur leader (11) et réplication automatiquement de l’information aux référentiels (6) de chacun des autres nœuds maîtres (4). d. Mise à jour par les services découverts (8) de chaque nœud, maître (4) et/ou esclave (9), de ses répartiteurs de charge (5) respectifs.
  8. 8. Système comportant des moyens adaptés pour la mise en œuvre du procédé selon la revendication 1, caractérisé en ce qu’il comporte: a. d’une à plusieurs bases de registres (2), publique et/ou privée, périodiquement répliquées, sur un fournisseur ou une infrastructure en nuage (13) ou sur une autre base de registres, publique et/ou privée, et hébergeant au moins un conteneur contenant des images de services (3) pour chaque service (10) proposé b. d’au moins un système d’exploitation (1) composé d’au moins un nœud maître (4) et au moins un nœud esclave (9) comportant: c. un répartiteur de charges (5), un service découverte (8), un protocole d’authentification nécessaire pour accéder à la et/ou les bases de registre (2) en mode privé et/ou des moyens pour déployer des services (10), dont le nœud maître (4) comporte, en plus, un orchestrateur (7) et un référentiel (6).
  9. 9. Système selon la revendication 8, dans lequel chaque système d’exploitation (1) est caractérisé en ce qu’il comporte un nœud maître leader (12) et un orchestrateur leader (11) basé sur le dit nœud maître leader (12) ou sur un autre nœud maître (4).
  10. 10. Système selon les revendications 8 et 9, caractérisé en ce que: a. le nœud maître leader (12) est remplacé automatiquement par un autre nœud maître (4), lors d’une défaillance du nœud maître leader (12) b. l’orchestrateur leader (11) est remplacé automatiquement par un autre orchestrateur (7), lors d’une défaillance de l’orchestrateur leader (11).
FR1501505A 2015-07-15 2015-07-15 Systeme et procede automatique de deploiement des services sur un noeud reseau Expired - Fee Related FR3039024B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1501505A FR3039024B1 (fr) 2015-07-15 2015-07-15 Systeme et procede automatique de deploiement des services sur un noeud reseau
BR102015025779A BR102015025779A2 (pt) 2015-07-15 2015-10-09 sistema e processo automatico de implementação de serviços em uma rede de nós

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1501505A FR3039024B1 (fr) 2015-07-15 2015-07-15 Systeme et procede automatique de deploiement des services sur un noeud reseau
FR1501505 2015-07-15

Publications (2)

Publication Number Publication Date
FR3039024A1 true FR3039024A1 (fr) 2017-01-20
FR3039024B1 FR3039024B1 (fr) 2018-06-29

Family

ID=54937124

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1501505A Expired - Fee Related FR3039024B1 (fr) 2015-07-15 2015-07-15 Systeme et procede automatique de deploiement des services sur un noeud reseau

Country Status (2)

Country Link
BR (1) BR102015025779A2 (fr)
FR (1) FR3039024B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114024841A (zh) * 2021-08-04 2022-02-08 统信软件技术有限公司 一种服务器集群部署方法、装置、计算设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003021465A1 (fr) * 2001-09-05 2003-03-13 Pluris, Inc. Procede et appareil de mise a niveau du logiciel d'un routeur en cours de fonctionnement
US20060235972A1 (en) * 2005-04-13 2006-10-19 Nokia Corporation System, network device, method, and computer program product for active load balancing using clustered nodes as authoritative domain name servers
WO2013028636A1 (fr) * 2011-08-19 2013-02-28 Panavisor, Inc Systèmes et procédés de gestion d'infrastructure virtuelle
US20140137259A1 (en) * 2012-11-09 2014-05-15 International Business Machines Corporation Methods and apparatus for software license management

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003021465A1 (fr) * 2001-09-05 2003-03-13 Pluris, Inc. Procede et appareil de mise a niveau du logiciel d'un routeur en cours de fonctionnement
US20060235972A1 (en) * 2005-04-13 2006-10-19 Nokia Corporation System, network device, method, and computer program product for active load balancing using clustered nodes as authoritative domain name servers
WO2013028636A1 (fr) * 2011-08-19 2013-02-28 Panavisor, Inc Systèmes et procédés de gestion d'infrastructure virtuelle
US20140137259A1 (en) * 2012-11-09 2014-05-15 International Business Machines Corporation Methods and apparatus for software license management

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114024841A (zh) * 2021-08-04 2022-02-08 统信软件技术有限公司 一种服务器集群部署方法、装置、计算设备及存储介质
CN114024841B (zh) * 2021-08-04 2023-09-19 统信软件技术有限公司 一种服务器集群部署方法、装置、计算设备及存储介质

Also Published As

Publication number Publication date
FR3039024B1 (fr) 2018-06-29
BR102015025779A2 (pt) 2017-01-24

Similar Documents

Publication Publication Date Title
JP7203444B2 (ja) 代替サーバ名を使用する相互トランスポート層セキュリティを選択的に提供すること
US10346443B2 (en) Managing services instances
JP6445222B2 (ja) エッジ位置でのカスタマイズ可能なイベントトリガ型計算のためのシステム、方法、及びコンピュータ可読記憶媒体
US11748090B2 (en) Cloud services release orchestration
US10771351B2 (en) Fast provisioning service for cloud computing
US20180373517A1 (en) Systems, methods, and apparatuses for docker image downloading
US10848582B2 (en) Customizable event-triggered computation at edge locations
Kangjin et al. Fid: A faster image distribution system for docker platform
CN104011701A (zh) 内容传送网络
CN108173774B (zh) 一种客户端的升级方法及系统
US10440106B2 (en) Hosted file sync with stateless sync nodes
US20190205172A1 (en) Computer-implemented methods and systems for optimal placement and execution of software workloads in a geographically distributed network of compute nodes
EP3465427A1 (fr) Exécution répartie chorégraphiée de programmes
EP3304304B1 (fr) Infrastructure informatique en nuage
US20180307502A1 (en) Network booting in a peer-to-peer environment using dynamic magnet links
CN113660315B (zh) 一种云计算服务提供方法、装置、设备及可读存储介质
FR3039024A1 (fr) Systeme et procede automatique de deploiement des services sur un noeud reseau
Pereira et al. Management of virtual machine images in heterogeneous clouds
EP2729874B1 (fr) Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration
FR3067832A1 (fr) Fourniture de services inter-groupements
EP3080706B1 (fr) Procédé de sauvegarde de données stockées sur un terminal
Panarello et al. Cloud federation to elastically increase mapreduce processing resources
Bohora Design and Develop Decentralized Microservices Architecture with Docker Container
Banerjea et al. Publish/subscribe-based p2p-cloud of underutilized computing resources for providing computation-as-a-service
Sabharwal et al. Getting started with HashiCorp consul

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20170120

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 6

ST Notification of lapse

Effective date: 20220305