Brevet FR3040805A1 — publié le 20170310

- 1 - La présente invention concerne le domaine technique des services informatiques en nuage de haute disponibilité et de haute fiabilité Dans l'état de la technique, il existe des méthodes de gestion de la disponibilité des machines physiques, des machines virtuelles, aussi bien que des noeuds sous des systèmes en nuage. Ces méthodes fonctionnent normalement avec des gestionnaires de machines virtuelles qui surveillent le bon fonctionnement des noeuds, ou des machines physiques qui exécutent plusieurs machines virtuelles. Le gestionnaire de machines virtuelles a pour rôle de redémarrer les machines virtuelles qui présentent des défaillances, ou de choisir une autre machine physique pour redémarrer les machines virtuelles, lorsque la défaillance est issue de la machine physique. Une autre solution est la réplication des machines virtuelles sur d'autres machines physiques. Il existe également des méthodes de gestion des applications et/ou des services. Les applications et/ou services peuvent être configurés pour être disponibles régulièrement ou non. Les méthodes varient selon cette configuration. Pour les applications et/ou services de haute disponibilité, le Forum des Services disponibles (Service Availability Forum) a déjà décrit un intergiciel (middleware) qui gère la haute disponibilité des applications. Il s'agit de l'intergiciel API - Application Programming Interface. L'usage d'un tel intergiciel comme outil de gestion de la disponibilité des applications est décrit dans le document WO 2014/128597 Ericsson, intitulé method and system for providing high availability for state-ware applications. Un tel document décrit, en outre, l'attribution d'une partie de la charge du travail à une base de données, pour sauvegarder et récupérer l'état de l'application logiciel, l'autre partie étant réservée à l'intergiciel. Une telle méthode fait appel à une base de données assez robuste pour sauvegarder l'état de l'application logiciel chaque fois qu'une vérification est réalisée. 3040805 - 2 - Il existe d'autres outils pour la gestion de la disponibilité des applications de service (availability management framework), comme décrit dans le document WO 2014/177950 de Ericsson, intitulé Availability management of virtual machines hosting highly available applications. 5 Un tel document décrit une méthode qui permet de gérer un service de haute disponibilité exécuté sur un ensemble de noeuds. Une telle méthode ne rend pas possible une gestion de services de haute 10 disponibilité qui anticipe et évite de possibles interruptions causées par des pannes de services. Or, les services de haute disponibilité sont considérés ainsi car ils doivent être disponibles plus de 99% du temps. Une méthode de gestion de tels services qui ne 15 présente pas des moyens pour anticiper et éviter des possibles interruptions serait donc incomplète. La présente invention a donc pour but de résoudre les problèmes techniques mentionnés ci-dessus, à savoir, la nécessité de la présence d'une base de données 20 robuste et la non anticipation des possibles interruptions causées par des pannes de services, en proposant un procédé de mise en place et maintenance de services de haute disponibilité dans un système d'exploitation en nuage. Glossaire: 25 Le terme "service de haute disponibilité" utilisé dans la présente invention peut être compris de façon non limitative comme "long-run service" et/ou un programme installé depuis une base de registre qui est exécuté sur un noeud esclave et/ou un service configuré pour être exécutable et disponible tout le temps ou à 99,99% du 30 temps. Le terme "noeud" 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", 3040805 - 3 - "réseaux de serveurs", "cluster", "ferme de serveurs", "ferme de noeuds". Un noeud peut être esclave ou maître. Un noeud maître peut communiquer avec un ou plusieurs noeuds esclaves. Un noeud esclave peut seulement communiquer avec un noeud maître. 5 Le terme "système de sûreté intégré" utilisé dans la présente invention peut être compris de façon non limitative comme un système de sûreté de non défaillance ou système de sécurité intégré, "fail-safe", "reprise après erreur". 10 Le terme "en nuage" utilisé dans la présente invention peut être compris de façon non limitative comme "plate-forme en nuage", "cloud", "plateforme cloud". 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 15 d'orchestration de contenu", "processus automatique d'organisation, de coordination, et de gestion de systèmes informatiques complexes", "orchestration de la gestion de services" ou composante d'un noeud destiné à lancer et gérer les services de haute disponibilité, lorsqu'il ordonne l'arrêt, le démarrage et/ou le redémarrage d'un service, aussi comme destiné à piloter les installations de service, à savoir la mise à 20 jour d'une base de registre. Le terme "répartiteur de charge" utilisé dans la présente invention peut être compris de façon non limitative comme "équilibrateur de charge", "load balancer", "dispositif de partage de charges", "dispositif de division de flux de réseau". 25 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 30 ERROR dans un format lié au protocole. 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 noeud" et/ou un ensemble de noeud (ferme de noeud) répondant à des 3040805 - 4 - principes déterminés et ayant au moins un maître et d'un à plusieurs esclaves. Le système d'exploitation, sur sa forme minimale peut ainsi être constitué uniquement d'un noeud. Et il peut aussi être constitué de multiples noeuds. 5 DESCRIPTION DE L'INVENTION: La présente invention concerne un système et un procédé de mise en place et maintenance des services de haute disponibilité dans un système d'exploitation en nuage, dans lequel une des étapes consiste dans la mise à jour du nombre 10 d'instances de services de haute disponibilité disponibles sur un ou plusieurs noeuds selon les résultats établis par un contrôle. Les dessins annexés illustrent l'invention: 15 La figure 1 représente un système d'exploitation (1) composé d'un moins un noeud maître (2), un ou plusieurs noeuds esclave (3), un orchestrateur (4) et un répartiteur de charges central (5). Elle représente aussi les répartiteurs de charges (6) de chaque noeud (2-3) et les instances de services (7) de haute disponibilité démarrées sur les noeuds esclaves. 20 La figure 2 représente, à titre d'exemple et de façon non limitative, un orchestrateur (4) qui ordonne le lancement des trois instances de service (7) de haute disponibilité sur au moins un noeud esclave (3) du système d'exploitation (1). 25 La figure 3 représente, à titre d'exemple et de façon non limitative, la consommation par chaque service (7) de ressources matérielles de trois instances d'un service (7) de haute disponibilité. La figure 4 représente le diagramme d'action qu'illustre le processus de mise à jour 30 des instances de services (6) de haute disponibilité par l'orchestrateur (4) sur les noeuds esclaves (3). En référence à ces dessins, le système d'exploitation (1) est composé d'au moins un noeud maître (2) et d'un ou plusieurs noeuds esclave (3). 3040805 - 5 - Ces noeuds (2 - 3) peuvent être physiques et/ou virtuels et ils communiquent entre eux par au moins un protocole de communication et de sécurité UDP, TCP, INPROC, IPC ou PGM. 5 Chaque noeud esclave (3) possède un répartiteur de charge (6) et des moyens pour déployer des services de haute disponibilité. Le système d'exploitation (1), selon l'invention, est composé d'un moins un noeud 10 maître (2) et un ou plusieurs noeuds esclaves (3). Un noeud (2) maître peut communiquer avec un ou plusieurs noeuds (3) esclaves. Le système d'exploitation (1) est placé sur une plate-forme en nuage. 15 Idéalement, au moins un noeud (2 - 3) du système d'exploitation (1) comporte des ressources matérielles. Le système d'exploitation (1) comprend un orchestrateur (4). 20 L'orchestrateur (4) peut être contenu dans n'importe quel noeud (2 - 3) .De préférence, l'orchestrateur (4) est situé sur le noeud (2) maître. L'orchestrateur (4) sera donc positionné sur un noeud maître (2) dans l'ensemble des exemples mentionnés ci-dessous. 25 L'orchestrateur (4) est destiné à ordonner des lancements d'instances de services (7) de haute disponibilité, arrêter des instances de services (7) de haute disponibilité, démarrer des nouvelles instances de service si les ressources libres sont suffisantes, interroger des bases de registres privées et/ou publiques, à fin d'ajouter des services à partir du téléchargement des images de services, entre autres, cette liste n'étant 30 pas exhaustive. L'orchestrateur (4) contient comme configuration, au moins, les adresses des noeuds (2 - 3) physiques et virtuels qui le composent, la configuration de haute disponibilité, long-run, et les adresses des bases de registres privées et/ou publiques. 3040805 - 6 - Le système d'exploitation (1) comprend également des services de haute disponibilité configurés pour être exécutable et disponibles tout le temps ou à 99,99% du temps. 5 Chaque service de haute disponibilité est défini par un nom d'instance et une adresse unique, qui permet la configuration de ce service auprès des répartiteurs de charge (6) de chaque noeud (2 - 3). Chaque service de haute disponibilité est configuré afin qu'un certain nombre d'instance de ce service soit disponible constamment. Le nombre d'instances déployées de ce service doit correspondre au nombre d'instances configuré dudit service (7). 15 Le système d'exploitation (1) comporte un répartiteur de charges central (5), point d'entrée des requêtes et destiné à répartir la charge sur les différents noeuds esclaves (3). Ce système d'exploitation (1) possède également des moyens pour établir une 20 communication par le biais d'au moins un protocole de communication et de sécurité UDP, TCP, INPROC, IPC ou PGM avec au moins une base de registre privée et/ou publique ayant des conteneurs d'images des services de haute disponibilité. DESCRIPTION DÉTAILLÉ DES RÉALISATIONS 25 Dans une réalisation, selon les schémas représentés par les figures, et de façon non limitative, chaque service de haute disponibilité, long-run, est configuré pour être disponible tout le temps ou à 99,99% du temps. Ainsi, il est également configuré pour être exécuté par une ou plusieurs instances de services (7) de haute disponibilité. Ce 30 nombre d'instances de services (7) de haute disponibilité doit être disponible tout le temps ou à 99,99% du temps disponible sur l'ensemble des noeuds esclaves (3) du système d'exploitation (1). 3040805 - 7 - L'orchestrateur (4) est configuré pour déployer une ou plusieurs instances de services (7) de haute disponibilité sur un ou plusieurs noeuds esclaves (3). En cas de panne d'un noeud esclave (3) où sont démarrées une ou plusieurs instances d'un service (7) de haute disponibilité, l'orchestrateur (4) déploiera à nouveau 5 automatiquement les instances de ce service (7) de haute disponibilité sur un ou plusieurs autres noeuds esclaves (3). La première étape est le lancement d'au moins une instance de services (7) de haute disponibilité par l'orchestrateur (4). 10 En parallèle, l'orchestrateur (4), réalise, selon une fréquence paramétré, des contrôles sur les noeuds esclaves (3) afin vérifier le nombre d'instances de services (7) de haute disponibilité disponibles et fonctionnant correctement. 15 La fréquence de contrôle réalisée par l'orchestrateur (4) est paramétrable par un administrateur du système. Dans cette réalisation, l'étape suivante correspond à la répartition de la charge par le répartiteur de charges central (5) du système d'exploitation (1), vers au moins un 20 répartiteur de charges (6) d'un noeud esclave (3) pour exécuter le service de haute disponibilité et haute fiabilité. Et l'étape finale correspond à l'exécution du service de haute disponibilité requêté. Dans une autre réalisation, l'orchestrateur (4) va réaliser des contrôles sur les noeuds 25 esclaves (3) afin de vérifier que le nombre d'instances de services (7) de haute disponibilité disponibles correspond au nombre d'instances de services (7) de haute disponibilité nécessaires pour déployer le service de haute disponibilité requêté. L'orchestrateur (4) réalise, donc, une mise à jour du nombre d'instances de service 30 (7) de haute disponibilité disponibles sur l'ensemble des noeuds esclave (3) du système d'exploitation (1) selon le résultat du contrôle. Si le résultat du contrôle indique que le nombre d'instances de services (7) de haute disponibilité sur l'ensemble des noeuds esclave (3) est inférieur au nombre 3040805 - 8 - d'instances paramétrées, l'orchestrateur (4) relance les instances (7) une par une sur l'ensemble des noeuds esclave (3) jusqu'à ce que le nombre d'instances dudit services (7) de haute disponibilité soit égal au nombre d'instances paramétrées; tant que les ressources du système d'exploitation le permettent. Ainsi, l'orchestrateur (4) 5 va démarrer des nouvelles instances de service (7) si les ressources libres sont suffisantes. Cette insuffisance du nombre d'instances de services (7) de haute disponibilité sur l'ensemble des noeuds esclaves (3) pour déployer le service de haute disponibilité requêté, peut être due à une panne d'un noeud ou d'une interruption d'une des instances de service (7) de haute disponibilité présente sur l'ensemble des noeud. Lorsque l'orchestrateur (4) relance les instances (7), celles-ci sont automatiquement installées sur au moins un noeud esclave (3) du système d'exploitation (1) qui 15 possède les ressources matérielles disponibles. Commodément, le système d'exploitation (1) possède des moyens pour établir une communication par le biais d'au moins un protocole de communication et de sécurité UDP, TCP, INPROC, IPC ou PGM avec au moins une base de registre privée et/ou 20 publique ayant des conteneurs d'images des services de haute disponibilité, ce qui rendre possible le téléchargement et l'accessibilité des images de ces services par les noeuds (2 - 3). Si le résultat du contrôle indique que le nombre d'instances de services (7) de haute 25 disponibilité sur l'ensemble des noeuds esclave (3) est supérieur au nombre d'instances configurées pour déployer un service de haute disponibilité, l'orchestrateur (4) arrêtera les instances (7) en trop. Ce nombre d'instances de services (7) de haute disponibilité déployées sur 30 l'ensemble des noeuds esclave (3) supérieur au nombre configuré par un administrateur peut être dû à un mécanisme de reprise après erreur ou système de sûreté intégré (fail-safe), où les instances de services (7) qui étaient interrompues ou en panne redeviennent opérables. Ce système de sûreté intégré (fail-safe) permet aux instances de service d'être redéployées automatiquement en cas de panne. 3040805 - 9 - Ainsi, il est possible que le système d'exploitation (1) contienne un nombre d'instances de services (7) disponibles supérieur au nombre paramétré pour le déploiement d'un service de haute disponibilité. Dans l'idéal, chaque noeud esclave (3) comporte des moyens pour ajouter, déployer, 5 exécuter et arrêter des services de haute disponibilité à partir des ordres de l'orchestrateur (4). Encore dans cette réalisation, l'étape suivante à la mise à jour du nombre d'instances de service (7) de haute disponibilité disponibles sur l'ensemble de 10 noeuds esclave (3) du système d'exploitation (1), correspond à la répartition de la charge par le répartiteur de charges central (5) du système d'exploitation (1), vers au moins un répartiteur de charges (6) d'un des noeuds esclave (3) pour exécuter le service de haute disponibilité et haute fiabilité. Et l'étape finale correspond à l'exécution du service de haute disponibilité requêté. 15 Ainsi, le système et le procédé selon l'invention sont particulièrement destinés à anticiper des possibles interruptions pour panne de services, en proposant un procédé de mise en place et maintenance des services de haute disponibilité en nuage. 20 REVENDICATIONS1. Procédé automatique de mise en place et maintenance de services de haute disponibilité dans un système d'exploitation en nuage, caractérisé en ce qu'il comprend les étapes suivantes: a. lancement d'une ou plusieurs instances de services (7) qui fournissent le service de haute disponibilité par un orchestrateur (4) ; b. en parallèle, réalisation des contrôles sur au moins un noeud esclave (3) pour vérifier le nombre d'instances de services (7) de haute disponibilité disponibles ; c. mise à jour du nombre d'instances de service (7) de haute disponibilité disponibles sur l'ensemble de noeuds esclave (3) selon résultat du contrôle: i. si le nombre d'instances de services (7) de haute disponibilité est inférieur au nombre d'instances paramétrées, l'orchestrateur (4) relance les instances (7) une par une sur l'ensemble des noeuds esclave (3) jusqu'à ce que le nombre d'instances dudit services (7) soit égal au nombre d'instances paramétrées; ii. si le nombre d'instances de services (7) de haute disponibilité est supérieur au nombre d'instances configurées pour déployer un service de haute disponibilité, l'orchestrateur (4) arrête les instances (7) en trop. d. répartition de la charge vers au moins un répartiteur de charges (6) d'un des noeuds esclave (3) pour exécuter le service de haute disponibilité ; e. exécution du service de haute disponibilité requêté. 2. Procédé selon la revendication 1, caractérisé en ce que l'orchestrateur (4) réalise, selon une fréquence paramétrée, des contrôles sur les noeuds esclave (3) afin de vérifier le nombre d'instances de services (7) de haute disponibilité disponibles. 3. Procédé selon la revendication 1, caractérisé en ce que la fréquence de contrôle par l'orchestrateur (4) est paramétrable. 3040805 4. Procédé selon la revendication 1, caractérisé en ce qu'en cas de panne d'un noeud esclave (3) où est démarré une ou plusieurs instances d'un service (7) de haute disponibilité, l'orchestrateur (4) redéployera automatiquement les 5 instances de ce service (7) de haute disponibilité sur un ou plusieurs autre noeuds esclaves (3). 5. Système d'exploitation en nuage pour mettre en oeuvre le procédé selon la revendication 1, caractérisé en ce qu'il comporte: 10 a. plusieurs noeuds (2 - 3) physiques et/ou virtuels communicant entre si par au moins un protocole de communication et de sécurité UDP, TCP, INPROC, IPC ou PGM ; b. un répartiteur de charges central (5) destiné à répartir la charge sur les différents noeuds esclaves (3) ; 15 c. un orchestrateur (4) destiné à: i. ordonner des lancements des instances de services (7) de haute disponibilité ; ii. arrêter des instances de services (7) de haute disponibilité ; iii. interroger des bases de registres privées et/ou publiques à fin 20 d'ajouter des services à partir du téléchargement des images de services. d. des services de haute disponibilité configurés pour être exécutable et disponible tout le temps ou à 99,99% du temps ; e. des moyens pour établir une communication par le biais d'au moins un 25 protocole de communication et de sécurité UDP, TCP, INPROC, IPC ou PGM avec au moins une base de registre privée et/ou publique ayant des conteneurs d'images des services de haute disponibilité. 6. Système selon la revendication 5, caractérisé en ce que l'orchestrateur (4) est 30 configuré pour déployer une ou plusieurs instances de services (7) de haute disponibilité sur un ou plusieurs noeuds esclaves (3).