1. Domaine

L'invention se rapporte à l'intégration de grandes quantités de ressources de calcul. La présente technique se rapporte plus particulièrement à l'intégration de grands ensembles de ressources disponibles pour réaliser des traitements. Plus spécifiquement encore, la technique décrite offre la possibilité d'intégrer, d'une manière centralisée, des ensembles de ressources informatisées de traitement applicatif de manière simple et intuitive, tout en permettant une vue d'ensemble des ressources.

2. Art Antérieur

Des organisations exploitent des réseaux informatiques qui interconnectent de nombreuses ressources informatiques pour mettre en œuvre leurs opérations, par exemple lorsque les ressources informatiques sont colocalisées (par exemple dans le cadre d'un réseau local) ou situées dans plusieurs emplacements géographiques distincts (par exemple connectées via un ou plusieurs réseaux intermédiaires privés ou publics). Les centres de données (Datacenters) hébergeant un nombre important de ressources informatiques interconnectées sont devenus monnaie courante. Il existe des centres de données privés exploités par et pour le compte d'une seule organisation et des centres de données publics exploités par des entreprises pour fournir des ressources informatiques à ses clients. Certains opérateurs de centres de données publics fournissent un accès réseau, de l'alimentation et des installations sécurisées pour le matériel appartenant à divers clients, tandis que d'autres exploitants de centres de données publics offrent des installations de type "service complet" incluant également des ressources matérielles mises à la disposition de leurs clients. Cependant, avec l'augmentation de la taille et de la portée des centres de données de ce type, les tâches de provisionnement, d'administration et de gestion des ressources informatiques sont devenues de plus en plus complexes.

Le déploiement massif des technologies de virtualisation a apporté des avantages en termes de gestion des ressources informatiques à grande échelle pour de nombreux clients ayant des besoins divers, permettant ainsi à plusieurs clients de partager efficacement et en toute sécurité diverses ressources informatiques. Par exemple, les technologies de virtualisation peuvent permettre à une seule machine informatique physique d'être partagée entre plusieurs utilisateurs en fournissant à chaque utilisateur une ou plusieurs machines virtuelles hébergées par la seule machine informatique physique. Chaque machine virtuelle peut être considérée comme une simulation logicielle agissant comme un système informatique logique distinct qui donne aux utilisateurs l'illusion qu'ils sont les seuls opérateurs et administrateurs d'une ressource informatique matérielle donnée, tout en assurant l'isolation et la sécurité des applications entre les différents systèmes virtuels. En outre, certaines technologies de virtualisation sont capables de fournir des ressources virtuelles couvrant au moins deux ressources physiques, telles qu'une seule machine virtuelle dotée de plusieurs processeurs virtuels couvrant plusieurs ressources informatiques physiques distincts.

Au fur et à mesure que les fonctionnalités prises en charge par les fournisseurs de ressources de calcul, de stockage et de réseau virtualisés se développent et que le nombre de plates-formes matérielles utilisées par les fournisseurs à grande échelle se développe, la mise en œuvre d'opérations de contrôle sur les plates-formes, telles que la gestion du trafic réseau flux, peut lui-même devenir assez complexe. Dans de nombreux cas, la fonctionnalité et la convivialité des applications exécutées sur de telles plates-formes peuvent largement reposer sur des communications réseau avec d'autres parties du réseau du fournisseur et/ou avec des entités externes telles que des clients ou des tiers. Dans le but d'atteindre les niveaux de performances souhaités pour les applications, les opérateurs de tels systèmes distribués peuvent d'une part avoir mis en place des infrastructures de réseau à bande passante élevée et d'autre part avoir outrageusement surdimensionner les capacités de calcul et de traitement des infrastructures et ce dans le seul but de faire face à la montée en charge et aux pannes. Cependant, malgré la mise à disposition de liaisons et de périphériques réseau à bande passante élevée, et l'augmentation des ressources de traitement, la gestion des infrastructures, des ressources et des applications qui s'exécutent au sein de ces ressources passe souvent par une gestion par liste. La virtualisation peut compliquer encore plus la gestion de la bande passante réseau (ainsi que la latence et d'autres caractéristiques réseau), car les diverses machines virtuelles mises en œuvre sur une plate forme matérielle unique peuvent avoir des exigences très diverses qui doivent être satisfaites à l'aide des composants réseau partagés de la plateforme et aussi parce que l'ensemble des applications et des machines virtuelles instanciées sur une plate-forme matérielle donnée peut changer au fil du temps. Pour faire face aux difficultés d'administration, la solution réside souvent par la remontée d'évènements au niveau d'une interface d'administration, laquelle est utilisée par un opérateur qui voit apparaître les évènements (comme les dysfonctionnements matériels ou logiciels) sous la forme d'une liste. Or cette manière de faire est assez peu efficace, d'une part car l'obtention d'une information complète relative à l'évènement ne permet généralement pas à l'opérateur de considérer cet évènement par rapport à son environnement : l'opérateur ne dispose pas d'information sur la tâche, l'application ou la ressource, sous une forme contextuelle, c'est-à-dire par rapport à son environnement. Or, par exemple lorsqu'une tâche est en défaut (cas d'un thread applicatif en défaut), il peut être intéressant de contextualiser ce défaut par rapport à l'ensemble des threads d'une ressource physique ou virtuelle. Les solutions actuelles d'administration ne permettent pas de contextualiser la visualisation des évènements liés à l'exécution d'application ou de portions d'applications au sein d'un ensemble de ressources. Il existe donc un besoin de fournir une méthode qui permette une telle contextualisation.

3. Résumé

La méthode proposée par les inventeurs ne pose pas au moins certains de ces problèmes de l'art antérieur. En effet, il est proposé un procédé d'intégration de traitement de données événementielles, procédé mis en œuvre par un dispositif électronique connecté à un réseau de communication, lesdites données événementielles provenant d'au moins une ressource, ladite au moins une ressource étant connu dudit dispositif électronique et identifiée au sein d'une liste de ressources. Un tel procédé comprend :

une étape d'affichage, sur un écran connecté au dispositif électronique, d'une représentation multidimensionnelle initiale d'un ensemble de ressource, ladite représentation multidimensionnelle comprenant, pour une ressource et/ou un processus donné, un affichage d'un état initial ;

au moins une itération d'une étape de réception, en provenance d'au moins une ressource informatique, d'un évènement courant de ressource et/ou d'un évènement d'un processus s'exécutant sur ladite ressource ;

au moins une itération d'une étape de traitement de la représentation multidimensionnelle de l'ensemble de ressource comprenant une mise à jour de la représentation de la ressource et/ou du processus en fonction de l'évènement courant et d'un état antérieur de la ressource et/ou du processus.

Ainsi, l'invention permet de simplifier l'affichage des évènements en provenance des ressources, nœuds et processus en cours d'exécution et proposant une représentation multidimensionnelle et visuelle de l'activité de l'ensemble des ressources. Par exemple lorsqu'on utilise une liste pour visualiser les ressources, elle ne tient pas sur la taille d'écran dès lors qu'il y a de nombreuses ressources. Ce n'est pas le cas avec l'invention puisque la représentation est adaptée à la quantité de ressources à afficher, soit en termes de taille de la représentation d'une ressource soit en termes de zoom/dézoom de cette des ressources au sein desquelles un évènement est survenu.

Selon une caractéristique particulière, le procédé comprend en outre au moins une étape de traitement, en provenance d'un périphérique d'utilisateur, d'une commande d'affichage de ladite représentation multidimensionnelle sur ledit écran. Selon une caractéristique particulière, l'étape d'affichage de la représentation multidimensionnelle initiale dudit ensemble de ressource comprend l'affichage d'une structure multidimensionnelle de base, comprenant une pluralité d'emplacements, chaque ressource et/ou processus de la liste de ressources étant assigné à un emplacement donné parmi l'ensemble des emplacements disponibles.

Selon un mode de réalisation particulier, l'étape d'affichage comprend en outre une étape de regroupement, sur la structure multidimensionnelle de base, des processus appartenant à une même ressource.

Selon une caractéristique particulière, l'étape mise à jour de la représentation de la ressource et/ou du processus en fonction de l'évènement courant et d'un état antérieur de la ressource et/ou du processus comprend une modification de la hauteur de la représentation de la ressource et/ou du processus.

Ainsi, l'invention rend possible la représentation d'exécution, sur de multiples ressources, d'une application ou d'une portion d'application, pour le gestionnaire d'infrastructures qui lui permet de visuellement se rendre compte de l'usage de ses ressources et qui lui permet d'éviter de surdimensionner son infrastructure afin que celle-ci puisse répondre aux défaillances constatées.

Il est entendu, dans le cadre de la description de la présente technique selon l'invention, qu'une étape de transmission d'une information et/ou d'un message d'un premier dispositif à un deuxième dispositif, correspond au moins partiellement, pour ce deuxième dispositif à une étape de réception de l'information et/ou du message transmis, que cette réception et cette transmission soit directe ou qu'elle s'effectue par l'intermédiaire d'autres dispositifs de transport, de passerelle ou d'intermédiation, y inclus les dispositifs décrits dans la présente selon l'invention.

Selon un autre aspect, l'invention se rapporte également à un dispositif électronique de traitement de données événementielles apte à être connecté à un réseau de communication, lesdites données événementielles provenant d'au moins une ressource, ladite au moins une ressource étant connu dudit dispositif électronique et identifiée au sein d'une liste de ressources. Le dispositif comprend des moyens d'affichage, sur un écran connecté au dispositif électronique, d'une représentation multidimensionnelle initiale d'un ensemble de ressource, ladite représentation multidimensionnelle comprenant, pour une ressource et/ou un processus donné, un affichage d'un état initial ; des moyens de réception, en provenance d'au moins une ressource informatique, d'un évènement courant de ressource et/ou d'un évènement d'un processus s'exécutant sur ladite ressource ;

des moyens de traitement de la représentation multidimensionnelle de l'ensemble de ressource comprenant une mise à jour de la représentation de la ressource et/ou du processus en fonction de l'évènement courant et d'un état antérieur de la ressource et/ou du processus.

L'invention se rapporte également, selon un aspect complémentaire, à un système d'exécution. Un tel système comprend au moins une ressource d'intégration, de type « master » prenant la forme d'un dispositif électronique d'exécution tel que décrit précédemment et au moins une ressource d'exécution accessible depuis la ressource d'exécution et apte à transmettre à celle-ci des informations d'état.

Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un dispositif d'exécution selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en œuvre au niveau du terminal de communication, du dispositif électronique d'exécution et/ou du serveur distant, dans le cadre d'une répartition des traitements à effectuer et déterminés par un codes source scripté.

En conséquence, l'invention vise aussi des programmes, susceptibles d'être exécutés par un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus.

Un programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus.

Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD.

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Selon un mode de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.

Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci- dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).

De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.

Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.

Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention.

4. Figures

D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :

la figure 1 décrit un système dans lequel l'invention est mise en œuvre ;

la figure 2 décrit les étapes de mises en œuvre de l'invention ;

la figure 3 illustre une première représentation d'un système selon l'invention ; la figure 4 illustre une deuxième représentation d'un système selon l'invention ; la figure 5 illustre une troisième représentation d'un système selon l'invention ;

la figure 6 illustre une architecture d'un dispositif apte à mettre en œuvre un procédé de traitement de l'invention.

5. Description

5.1. Exposé du principe

L'objet de l'invention, comme exposé précédemment, est de fournir une technique de gestion simple, efficace et intuitive de ressources informatiques physiques ou virtuelles. Plus particulièrement, l'invention offre une solution de gestion de grands ensembles de ressources de façon simple en proposant une représentation graphique combinée à une technique de modulation de la représentation en fonction des états des ressources informatiques. Au sein de cette représentation graphique, les ressources informatiques sont regroupées en cluster. Chaque cluster comprend un nombre prédéterminé de ressources informatiques (soit physique, soit virtuelle soit les deux) : un cluster peut représenter une grille de calcul ou un ensemble de grilles de calcul. L'invention offre la possibilité d'une part de gérer ces clusters individuellement et facilement et d'autre part de gérer individuellement chacune des ressources informatiques de ce cluster de façon totalement indépendante. Enfin, d'une manière générale, l'invention offre la possibilité de visualiser des évènements (anomalie/tâche en cours, charge) de manière simple et ce sans restreindre le champ de vision de l'utilisateur, c'est à dire sans limiter la vision que l'utilisateur peut avoir de l'ensemble de ressources.

Ces avantages sont obtenus par un procédé d'intégration de ressources informatiques, procédé comprenant la mise en œuvre d'une structure de données représentative d'un ensemble de ressources informatiques. Cette structure de données comprend, pour chaque ressource informatique, au moins une information d'état et au moins un cluster (nœud) d'appartenance. La structure de données est dimensionnée pour répondre aux besoins d'affichage de la représentation associée à l'ensemble des ressources informatiques qui est géré. Comme explicité ci-après, dans un mode de réalisation explicatif et non limitatif, la structure de données peut comprendre plusieurs milliers d'entrées et se présenter sous la forme d'un tableau ou encore d'une base de données. La structure de données est créée, alimentée et mise à jour par un serveur d'intégration de ressources informatiques. Pour les besoins de la description, un serveur d'intégration de ressources informatiques est appelé "master". En fonction des modes de réalisation, plusieurs serveurs « master » peuvent transmettre des données à afficher à un dispositif d'affichage donné. Le « master » dispose d'au moins une interface matérielle d'accès aux ressources. Cette (au moins une) interface matérielle d'accès aux ressources informatiques peut être complétée ou surchargée d'interfaces logiques d'accès à des ressources informatiques. Les ressources informatiques accédées par master sont du type ressources informatiques physiques et/ou ressource informatiques logiques (virtuelles). Une ressource informatique physique peut prendre la forme d'un serveur, d'un ordinateur personnel, d'un smartphone, d'une tablette ou encore d'un cœur d'un processeur multicœur. Plus généralement, une ressource informatique physique comprend une unité de calcul physiquement adressable et apte à mettre en œuvre un traitement informatisé d'une application (un programme) ou une partie d'application (une partie de programme). Une ressource informatique logique (virtuelle) peut prendre la forme d'une machine virtuelle (reproduisant comme explicité précédemment le fonctionnement d'une machine physique) s'exécutant sur une ou plusieurs ressources informatiques physique ou plus généralement d'un programme s'exécutant sur une ressource informatique physique (par exemple un interpréteur de code scripté ou de bytecode).

Dans le cadre de l'invention, on suppose qu'une ressource informatique peut, en fonction des modes de réalisation, être en charge de la mise en œuvre d'un ou de plusieurs "threads" (de l'anglais), également appelé processus, qui exécute une partie ou de la totalité d'une application par une ressource informatique (l'exécution pouvant également être appelée «job »). Dans le cadre de la présente, on suppose également que master est en mesure d'obtenir, de la part des ressources informatiques, l'état des threads qui s'exécutent au sein de la ressource informatique.

La figure 1 représente l'ensemble des ressources informatiques possibles telle que mise en œuvre dans l'invention. La structure de données représentative de l'ensemble des ressources informatiques comprend les informations illustrées en figure 1, soit sous une forme tabulaire (une ligne par enregistrement), soit sous la forme d'arbre. La constitution de la structure de données (SDAT) est adaptée aux conditions de mises en œuvre opérationnelle, afin de fournir un accès rapide au contenu de la structure de données. Par exemple, une base de données peut être adaptée à l'intégration d'un très grand nombre de ressources informatiques tandis qu'un fichier xml ou un fichier à plat de type "json" peut être adapté à un nombre plus faible de ressources informatiques.

Quoi qu'il en soit, comme explicité en figure 1, on considère qu'un cluster (un nœud) se rapporte à au moins une ressource informatique (physique ou logique). Une ressource informatique met en œuvre un ou plusieurs threads associés à l'exécution d'une partie ou de la totalité d'une application. Une ressource informatique peut se rapporter à plusieurs cluster (nœuds) en même temps. Dans un mode de réalisation particulier, un cluster comprend une pluralité de ressources et chaque ressource met en œuvre un et un seul thread à un instant donné (pas de concurrence d'accès aux ressources).

En possession de cette structure de données, le procédé de l'invention, tel qu'illustré en figure 2, comprend les étapes suivantes, mises en œuvre de manière itératives, pour permettre une restitution des données de la structure, par le « master » ou par un terminal auquel le « master » communique des données d'affichage :

une étape d'affichage (10), sur un écran connecté au dispositif électronique, d'une représentation multidimensionnelle initiale d'un ensemble de ressource, ladite représentation multidimensionnelle comprenant, pour une ressource et/ou un processus donné, un affichage d'un état initial ;

au moins une itération (20) d'une étape de réception, en provenance d'au moins une ressource informatique, d'un évènement courant de ressource et/ou d'un évènement d'un processus s'exécutant sur ladite ressource ;

au moins une itération (30) d'une étape de traitement de la représentation multidimensionnelle de l'ensemble de ressource comprenant une mise à jour de la représentation de la ressource et/ou du processus en fonction de l'évènement courant et d'un état antérieur de la ressource et/ou du processus.

Selon l'invention, la mise à jour de la représentation de la ressource et/ou du thread (processus) en fonction de l'état courant, comprend au moins une étape appartenant au groupe suivant :

pour un thread donné, parmi l'ensemble des threads en cours d'exécution, une modification de la hauteur et/ou de la forme de la représentation multidimensionnelle de ce thread en fonction de la charge de traitement associée à l'application ou à la portion d'application exécutée par ce thread ;

pour un thread donné, parmi l'ensemble des threads en cours d'exécution, une modification de la couleur de la représentation multidimensionnelle de ce thread en fonction de la charge de traitement associée à l'application ou à la portion d'application exécutée par ce thread ;

pour un thread donné, parmi l'ensemble des threads en cours d'exécution, une modification de la couleur de la représentation multidimensionnelle de ce thread en fonction de l'état de ce thread (état actif, inactif, en attente, en défaut, etc.) ;

pour une ressource donnée, parmi l'ensemble des ressources en cours d'utilisation, une modification de la couleur de la représentation multidimensionnelle de cette ressource en fonction de la charge de traitement associée à l'application ou à la portion d'application exécutée par au moins un thread sur ladite ressource ;

pour une ressource donnée, parmi l'ensemble des ressources en cours d'utilisation, une modification de la couleur de la représentation multidimensionnelle de cette ressource en fonction de l'état de cette ressource (état actif, inactif, en attente, en défaut, etc.) ;

pour un nœud donné, parmi l'ensemble des nœuds en cours d'utilisation, une modification de la couleur de la représentation multidimensionnelle de ce nœud en fonction de la charge de traitement associée à l'application ou à la portion d'application exécutée par au moins un thread sur une ressource associée à ce nœud ;

pour un nœud donné, parmi l'ensemble des nœuds en cours d'utilisation, une modification de la couleur de la représentation multidimensionnelle de ce nœud en fonction de l'état de ce nœud (état actif, inactif, en attente, en défaut, etc.) ;

Outre les modifications liées à la réception de données d'état ou d'exécution en provenance des nœuds/ressources/thread, la représentation graphique est également modifiable pour un utilisateur visualisant cette représentation sur l'écran du dispositif connecté au master. Les modifications de représentations liées à la manipulation effectuée par ou pour l'utilisateur comprennent notamment : la sélection, d'un nœud (cluster) parmi l'ensemble des nœuds disponibles ; cette action a pour conséquence de provoquer l'affichage d'un certain nombre d'informations se rapportant au nœud sélectionné, comme par exemple l'identifiant du nœud, son type, le nombre de ressources et/ou de thread dont le nœud se compose, le nombre de ressources utilisées et/ou de thread en cours d'exécution, la charge de traitement du nœud (mémoire, CPU, etc.)

la sélection d'une ressource parmi l'ensemble des ressources disponibles ; cette action a pour conséquence de provoquer l'affichage d'un certain nombre d'informations se rapportant à la ressource sélectionnée, comme par exemple l'identifiant de la ressource, son type, le nombre de thread associée à cette ressource, le nombre de thread en cours d'exécution, la charge de traitement de la ressource (mémoire, CPU, etc.)

la sélection, d'un thread parmi l'ensemble des threads disponibles ; cette action a pour conséquence de provoquer l'affichage d'un certain nombre d'informations se rapportant au thread sélectionné, comme par exemple l'identifiant du thread, son type, la charge de traitement sur la ressource (mémoire, CPU, etc.) l'utilisation d'une commande de zoom avant ou de zoom arrière de la représentation ; cette action a pour conséquence de provoquer, par le master ou par une application de visualisation, un affichage plus ou moins étendu (selon la commande utilisée),

l'utilisation d'une commande de rotation, translation, déplacement de la représentation.

Les modifications peuvent être mises en œuvre de manière automatique ou manuelle (par l'utilisateur lui-même. Cependant, le caractère automatique de la modification est privilégié lorsqu'un évènement de type « erreur » (blocage/abandon/echec) survient. L'application de visualisation qui gère la représentation dispose d'une structure de données représentant les ressources qui sont affichées (appelée structure de données d'affichage) à l'écran (et leur position sur l'écran) et une structure de données représentant l'ensemble des ressources (ces caractéristiques sont précisées par la suite). Lorsqu'un évènement reçu se rapporte à une ressource qui n'est pas affichée à l'écran ou qui n'est totalement visible ou encore une ressource qui n'est pas totalement centrée, alors l'application de visualisation effectue une ou plusieurs des actions précédemment mentionnées, pour le compte de l'utilisateur (c'est-à-dire en mode automatisé) afin de permettre à celui-ci de visualiser la ressource impactée de manière plus aisée.

Afin de faciliter l'administration des ressources (physiques ou virtuelles), nœuds (nodes) ou processus (thread), selon l'invention, des manipulations peuvent automatiquement être effectuées en fonction de la survenance d'évènements préalablement déterminés (défauts, modifications d'état, modifications de charge, etc). Par exemple, en cas de défaut sur une ressource, un nœud ou un processus, l'application mise en œuvre par le master et/ou par le terminal de visualisation connecté au master effectue un déplacement automatique vers la ressource, le nœud ou le processus en question pour le placer l'élément en défaut au centre de la vision de l'utilisateur, selon des paramètres de visualisation prédéterminés (en termes de zoom, de taille, de couleur, etc.). Astucieusement, ce déplacement peut s'accompagner, selon les modes de réalisation, d'une sélection automatique de cet élément afin de permettre l'affichage de ses propriétés. Dans un mode de réalisation particulier, des modifications de l'apparence de l'élément sélectionné (forme, couleur) peuvent également être mises en œuvre pour permettre son identification plus rapide par l'utilisateur (l'opérateur) et in fine permettre à celui-ci de réagir plus promptement lorsque des actions sont requises de sa part. Les modifications d'apparence peuvent comprendre toute modification de taille, couleur, forme, voir l'adjonction d'une animation. L'objectif étant de permette à l'opérateur d'identifier rapidement l'élément qui mérite l'attention afin d'exercer si possible les actions nécessaires. Les traitements mis en œuvre par le master pour modifier l'affichage en fonction des actions de l'utilisateur permettent à celui-ci de vérifier le fonctionnement et/ou l'exécution des nœuds/ressources/thread en fonctionnement lors de l'exécution d'une ou de plusieurs applications et ce de manière simple et intuitive. En effet, contrairement aux méthodes utilisées traditionnellement dans les centres de données, l'affichage produit par l'invention permet de localiser rapidement une anomalie de fonctionnement tout en dimensionnant l'architecture de manière optimale par rapport aux besoins. Plus particulièrement, après une phase d'initialisation, dans laquelle la représentation de l'ensemble des ressources/nœuds/thread est initialement dessinée (affichée), les modifications apportées à la représentation sont effectuées en faisant part, au terminal de communication (comprenant par exemple un navigateur) en transmettant des commandes (et/ou des requêtes) qui font part de modifications événementielles (i.e. évènement et données relatives à ces évènements), liées à un ou plusieurs ressources/nœuds/thread du master vers le terminal de communication.

Les figure 3 à 5 exposent, pour un mode de réalisation donné, la représentation visuelle en trois dimensions (tridimensionnelle) laquelle évolue au cours du temps (on obtient au final une représentation quadridimensionnelle (x,y,z,t)), obtenue pour différents états et différents angles de vue. Dans ce mode de réalisation, une représentation hexagonale est adoptée pour chaque thread. Une autre forme pourrait tout autant être mise en œuvre. Les représentations des threads sont positionnées sur un plan, qui peut avoir une taille prédéterminée. Ce plan constitue la représentation de base sur laquelle les autres représentations (thread, ressources, nœuds) sont affichées et mises à jour. Dans cette représentation, les nœuds et les threads différents ont tous la même couleur. Pour des questions de facilité de prise en charge et de sélection, il pourrait être envisagé de donner des couleurs différentes aux threads d'un nœud donnée, lors de la sélection d'un thread de ce nœud.

La figure 2 est une représentation de deux nœuds, comprenant à eux deux cinquante-huit threads (illustrés par le mot flow sur la copie d'écran), l'ensemble se trouvant dans un état inactif. Chaque thread est représenté par un même hexagone tridimensionnel, d'une hauteur et d'une couleur uniforme. Comme indiqué en partie gauche de l'écran, aucun job ne tourne et l'état du système est inactif. On visualise par ailleurs à l'écran un ensemble d'hexagones "vides", c'est à dire une représentation de l'ensemble des threads qu'il serait possible d'instancier dans le système. En partie droite de l'écran, un état général du système est représenté, comprenant notamment le nombre de nœuds, le nombre de threads, un état général d'utilisation de la ressource et une indication de pression exercé sur le système (représentant le nombre de nombre de travaux en attente). La figure 3 est une représentation des deux mêmes nœuds qu'en figure 2, comprenant à eux deux cinquante-huit threads (illustrés par le mot flow sur la copie d'écran), l'ensemble se trouvant dans un état actif. Plus particulièrement, cinquante threads sont dans un état actif (threads de couleur bleue et rouge) et huit threads sont dans un état inactif (comme dans la figure 2). Les threads de couleur bleue ont une hauteur supérieure à celle des threads de couleur rouge et noire. Ils indiquent qu'une tâche (un job) est en cours d'exécution sur le thread). La hauteur de la représentation varie en fonction de la charge, une charge élevée entraînant une hauteur élevée. Comme indiqué sur la figure, il y a quarante tâches (portions d'applications) en cours d'exécution sur la copie d'écran (num running flow = 40), tandis que le nœud comprend cinquante thread (num flow= 50). L'identifiant du nœud est inscrit en haut à gauche (node id). Les informations d'usage et de charge sont également présentes pour ce nœud. Les threads représentés en rouge sont ceux pour lesquels une défaillance se produit (il peut s'agir d'une défaillance matérielle ou logicielle). N'étant pas en exécution, la hauteur de la représentation de ces threads défaillant est inférieure à celle des threads en cours d'exécution. Une sélection d'un thread défaillant permet d'obtenir de l'information sur l'état du thread (et donc de la ressource) et de déterminer ou de constater l'origine de la défaillance rencontrée.

La figure 4 représente les mêmes nœuds et thread que dans la figure 3, à la différence d'une part que la représentation fait l'objet d'une rotation par l'utilisateur et d'autre part que le nombre de threads pour lesquels une tâche est en cours d'exécution n'est plus égal qu'à seize (num running flows = 16), les autres threads ayant terminé l'exécution des portions d'applications qu'ils exécutaient. Ils sont donc redevenus de couleur noire et leur hauteur a été ajustée en fonction de leur nouvel état.

Grâce à la mise en œuvre de la technique décrite ici, il est plus aisé, pour un gestionnaire de ressource (par exemple un opérateur assigné à la gestion des ressources) de constater rapidement et efficacement de l'état des ressources d'un système donné, avec ou sans exécution d'applications ou de portions d'applications, et ce sans qu'il soit nécessaire de rechercher dans une simple liste ou sans qu'il soit nécessaire de hiérarchiser les ressources pour permettre un suivi de celles-ci.

Afin d'illustrer une implémentation particulière, nous présentons ci-dessous un exemple de décodage de requête émises par un master vers un navigateur (type Firefox™, etc.) en charge de restituer l'interface précédemment illustrée. Dans cette implémentation, le master s'exécute sur un serveur et communique via une « socket » dédiée des requêtes avec un navigateur afin que ce dernier affiche la représentation d'un cluster en temps-réel.

Le format d'échange de données est dans ce cas un format JSON adapté à ces échanges. Pour matérialiser l'état d'un cluster, le master défini une structure de donnée « metrics ». Cette structure est composée de « nodes » représentant une ressource informatique. Un « node » (nœud) est représenté par un identifiant « id » et possède un « load » (charge) représentant la charge de la ressource, d'un « State » (état) représentant l'état de la ressource et d'une autre structure « flows » (flux) représentant les différents threads associés à cette ressource. Chaque « flow » possède son identifiant « Id » ainsi qu'un « State » représentant son état (« run » ou « wait » dans ce cas).

À titre d'exemple, voici une structure « metrics » utilisée dans cette implémentation. metrics = {

nodes : {

'nodeldl' : {

load: 10,

State : ' ok' ,

flows: {

' flowldl ' : {

State : 'run'

} ,

' flowId2 ' : {

State : 'wait'

} ,

' flowId3' : {

State : 'wait'

} ,

' flowId4 ' : {

State : 'wait'

}

Grâce à cette structure de donnée, l'application de visualisation (également appelée interface de visualisation) qui s'exécute dans le browser est à même de produire une représentation initiale de l'état d'un cluster.

Afin d'initialiser la visualisation le « master » transmet via une requête « setMetrics », l'état inital du cluster. Au sein de cette requête, « req. metrics » comprend la version de « metrics » à initialiser. Pour ce faire le navigateur réalise l'appel « new ClusterMetrics » qui permet de créer la structure de donnée « metrics » initiale et de mettre à jour la visualisation initiale du cluster sur l'interface.

Ensuite, le master transmet des requêtes lors de modifications d'état du cluster (pour des évènements se produisant sur le cluster). Astucieusement, les évènements transmis pour être représentés peuvent être « filtrés », par un composant de traitement d'évènements, comme cela est exposé par la suite. Comme indiqué précédemment dans cet exemple « Node » représente une ressource, « Job » représente un thread. Il existe ainsi un appel de fonction pour ajouter une ressource « addNode », ou la supprimer « removeNode », ou mettre son état de charge à jour « setNodeLoad » ou mettre son état (marche/erreur/suspendu,...) à jour « setNodeState ».

Dans cette implémentation la requête « addNode » indique l'identifiant associé à cette ressource (« nodeld »), ainsi qu'une structure « flows » qui comprend les identifiants (Ids) de chaque thread de la ressource. Afin de mettre à jour l'état des threads, le master transmet des requêtes « jobRun » pour indiquer qu'un job s'exécute ou « jobDone » pour indiquer que le thread attend.

Lors de chacun de ces appels, l'interface de visualisation est mise en jour par le navigateur et représente ainsi une vue temps-réel de l'état d'un cluster donné. L'avantage d'une telle implémentation est de limiter les échanges de données entre le master et le navigateur : en effet, une fois l'initialisation effectuée et la première représentation affichée par le navigateur, la quantité de données échangées entre le master et le navigateur est faible et se limite aux changements traités par le master et transmis au navigateur. Cela assure par ailleurs une plus grande réactivité du navigateur.

Dans ce mode de réalisation, autant l'appel de « addNode » ou « removeNode » est fait concomitamment lors de l'ajout ou de la suppression d'une ressource, tout comme « jobRun » ou « jobDone » pour un thread, autant les appels « setNodeLoad » ou « setNodeState » sont mis à jour à des périodes indéterminées en fonction de la configuration/et ou des traitements du master. Par exemple si le master traite des informations de charge des processeurs d'un ordinateur toute les minutes, l'appel « setNodeLoad » ne se fera que toute les minutes au minimum. Lorsque le master traite ses informations de charge des processeurs d'un ordinateur toute les secondes, il pourrait réaliser des requêtes « setNodeLoad » à chaque seconde. Le master possède cependant lui-même un composant de traitement d'évènements qui permet de décider de la fréquence de transmission des données au navigateur afin d'une part de ne pas surcharger celui-ci et d'autre part de prendre en compte les évolutions réelles et représentatives des charges ou autres évènements. Dans le cas précédent, le composant de traitement d'évènements peut déterminer qu'une mise à jour moins fréquente que la seconde est suffisante pour refléter la charge des processeurs et ne réaliser un appel à « setNodeLoad » que toutes les 10 secondes afin de limiter le trafic des requêtes sur le réseau. La valeur de charge transmise peut alors avantageusement être une moyenne des valeurs traitées par le master. Le master (composant de traitement d'évènements) est donc responsable, selon une politique prédéterminée, de la fréquence de ces requêtes « setNodeLoad » ou « setNodeState » (et d'une manière générale de la fréquence des évènements transmis, tout comme des valeurs associées à ces évènements, qui peuvent donc être représentatives de la situation d'un ou de plusieurs évènements, sans nécessairement être exactes). Cette manière de procéder assure que la représentation du cluster peut être affichées (et être exécutée) sur des terminaux de communications qui ne possèdent pas nécessairement une puissance de calcul et/ou de traitement et/ou une bande passante suffisante pour un traitement intensif. Cela permet par ailleurs d'éliminer des évènements non pertinents, comme par exemple des baisses ou augmentations de charge non significatives et/ou de ne pas afficher de comportements divergents (c'est- à-dire sans lien avec l'activité réelle). switch (req. action) {

// Initialisation de la vue

case ' setMetrics ' :

metrics = new ClusterMetrics (req .metrics ) ;

break;

// Gestion d'une ressource ou Nodes

// Ajout, suppression, changement d'état ou charge

case ' addNode ' :

metrics . addNode (req. nodeld, req. flows) ;

break;

case ' setNodeLoad ' :

showNodeLoad (req . load) ;

break;

case ' setNodeState ' :

showNodeState ( req . State ) ;

break;

case ' removeNode ' :

metrics . removeNode (req . nodeld) ;

break;

// Gestion d'une thread (job) pour une ressource donnée

// Ajout ou suppression d'un job sur un node

case ' j obRun ' :

metrics. 'jobRun' (req. nodeld, req.flowld) ;

break;

case ' j obDone ' :

metrics . j obDone (req. nodeld, req. flowld) ;

break;

}

Comme indiqué précédemment, à partir de cette structure de donnée « metrics », le navigateur permet de produire une visualisation d'un cluster. Par exemple cette dernière peut être construite au- dessus d'une interface 3D qui permet de prendre en charge la sélection, le zoom et autres manipulations des différents éléments, comme en figures 3 à 5.

Dans un mode de réalisation, complémentaire, l'application de visualisation génère, à réception, une structure de données d'affichage, qui pour chaque nœud (« node ») comprend des coordonnées d'affichage de ce nœud. Lorsqu'un nœud n'a pas de coordonnées d'affichage, soit il n'est pas dans la structure d'affichage ou alternativement il a des coordonnées non valorisées. La structure de données d'affichage peut être mise à jour en fonction des manipulations effectuées manuellement par l'utilisateur. Ce mode de réalisation complémentaire présente l'avantage de faciliter la visualisation des ressources pour lesquelles un évènement (par exemple une erreur) se produit. Concrètement, la structure de données d'affichage est créée par l'application de visualisation et comprend au moins une paire de coordonnées d'affichage pour charque nœud (ressource) affichée à l'écran, ainsi que l'identifiant de ce nœud. Cette structure de données est maintenue (modifiée) en temps réel en fonctions des manipulations de l'utilisateur notamment. Pour que ces modifications soient simple, un système de coordonnées simple (x,y) est préféré. Les translations, rotation zoom et dezoom manuels de l'utilisateur sont alors plus simple à répercuter sur la structure de données. Lorsqu'un évènement survient sur un nœud (une ressource), l'application de visualisation recherche si ce nœud est présent au sein de la structure de données d'affichage et s'il est présent, quelles sont ses coordonnées. Lorsque la ressource est « suffisamment » visible (le critère de suffisance pouvant être calculé de plusieurs manières différentes, notamment par rapport au centre de l'écran (i.e. distance « seuil » séparant l'affichage de la ressource par rapport au centre de l'écran)), alors aucune action n'est menée. Lorsque la ressource n'est pas suffisamment visible (voir non affichée), alors une ou plusieurs actions (rotation, homothétie, translation, zoom/dezoom) sont mises en œuvre par l'application de visualisation pour rendre la ressource visible (par rapport au seuil précédemment défini par exemple). Les coordonnées des ressources impactées sont mises à jour dans la structure d'affichage pour permettre la mise en œuvre automatique de ces actions. Par ailleurs, une action de sélection de la ressource (provoquant l'ouverture d'une fenêtre des propriétés de celle-ci) peut également être mise en œuvre. Ainsi, l'utilisateur est assuré d'être informé des évènements jugés importants (ceci étant bien sur paramétrables), même avec de très grandes quantités de ressources à gérer.

5.2. Autres caractéristiques et avantages

Dans au moins certains modes de réalisation, un serveur qui implémente une partie ou la totalité d'une ou plusieurs des technologies décrites ici, y compris les techniques pour implémenter les serveurs de configuration réseau, les gestionnaires de services de configuration réseau, les serveurs de visualisation de topologie et / ou les hôtes d'instance, peut: comprend un système informatique à usage général qui comprend ou est configuré pour accéder à un ou plusieurs supports accessibles par ordinateur. La figure 6 illustre un tel dispositif informatique à usage général 3000. Dans le mode de réalisation illustré, le dispositif informatique 3000 comprend un ou plusieurs processeurs 3010 couplés à une mémoire système 3020 via une interface d'entrée/sortie 3030. Le dispositif informatique 3000 comprend en outre interface réseau 3040 couplée à l'interface d'entrée/sortie 3030.

Dans divers modes de réalisation, le dispositif informatique 3000 peut être un système à un seul processeur comprenant un processeur 3010 ou un système à plusieurs processeurs comprenant plusieurs processeurs 3010 (par exemple deux, quatre, huit ou un autre nombre approprié). Les processeurs 3010 peuvent être n'importe quels processeurs appropriés capables d'exécuter des instructions. Par exemple, dans divers modes de réalisation, les processeurs 3010 peuvent être des processeurs à usage général ou embarqués mettant en œuvre l'une quelconque d'une variété d'architectures de jeux d'instructions (ISA), telles que les ISA x86, PowerPC, SPARC ou MIPS, ou tout autre ISA approprié. Dans les systèmes multiprocesseurs, chacun des processeurs 3010 peut généralement, mais pas nécessairement, mettre en œuvre le même ISA. Dans certaines mises en œuvre, des unités de traitement graphique (GPU) peuvent être utilisées à la place des processeurs classiques ou en plus de ceux-ci.

La mémoire système 3020 peut être configurée pour stocker des instructions et des données accessibles au (x) processeur (s) 3010. Dans divers modes de réalisation, la mémoire système 3020 peut être mise en œuvre en utilisant toute technologie de mémoire appropriée, telle qu'une mémoire vive statique (SRAM), une RAM dynamique synchrone (SDRAM).), mémoire non volatile / de type Flash ou tout autre type de mémoire. Dans le mode de réalisation illustré, les instructions de programme et les données mettant en œuvre une ou plusieurs fonctions souhaitées, telles que les procédés, techniques et données décrites ci-dessus, sont stockées dans la mémoire système 3020 sous la forme de code 3025 et de données 3026.

Dans un mode de réalisation, l'interface d'E/S 3030 peut être configurée pour coordonner le trafic d'entrée/sortie entre le processeur 3010, la mémoire système 3020 et tous les périphériques du dispositif, y compris l'interface réseau 3040 ou d'autres interfaces périphériques telles que divers types de données persistantes et / ou similaire ou des dispositifs de stockage volatils utilisés pour stocker des réplicas physiques de partitions d'objet de données. Dans certains modes de réalisation, l'interface E/S 3030 peut effectuer tout protocole nécessaire, toute synchronisation ou toute autre transformation de données pour convertir les signaux de données d'un composant (par exemple, la mémoire système 3020) en un format approprié pour être utilisé par un autre composant (par exemple, le processeur 3010). Dans certains modes de réalisation, l'interface d'entrée/sortie 3030 peut inclure la prise en charge de périphériques connectés via divers types de bus de périphériques, tels qu'une variante du standard de bus PCI (« Peripheral Component Interconnect ») ou du standard USB (« Universal Serial Bus »), par exemple. Dans certains modes de réalisation, la fonction de l'interface d'E/S 3030 peut être scindée en deux composants séparés ou plus, tels qu'un pont nord et un pont sud, par exemple. De même, dans certains modes de réalisation, une partie ou la totalité de la fonctionnalité de l'interface E/S 3030, telle qu'une interface vers la mémoire système 3020, peut être incorporée directement dans le processeur

3010. L'interface réseau 3040 peut être configurée pour permettre l'échange de données entre le dispositif informatique 3000 et d'autres dispositifs 3060 connectés à un réseau ou à des réseaux 3050, tels que d'autres systèmes ou dispositifs informatiques, comme illustré à la Fig. 1 et 2, par exemple. Dans divers modes de réalisation, l'interface réseau 3040 peut prendre en charge la communication via tout réseau de données général câblé ou sans fil approprié, tel que des types de réseau Ethernet, par exemple. De plus, l'interface réseau 3040 peut prendre en charge la communication via des réseaux de télécommunication / téléphonie tels que des réseaux vocaux analogiques ou des réseaux de communication numériques en fibre, via des réseaux de stockage tels que des réseaux SAN Fibre Channel ou via tout autre type de réseau et / ou protocole approprié.

Dans certains modes de réalisation, la mémoire système 3020 peut être un mode de réalisation d'un support accessible par ordinateur configuré pour stocker des instructions de programme et des données telles que décrites ci-dessus pour la Fig. 1 à la Fig. 5 pour mettre en œuvre des modes de réalisation des procédés et dispositifs correspondants. Cependant, dans d'autres modes de réalisation, des instructions de programme et / ou des données peuvent être reçues, envoyées ou stockées sur différents types de supports accessibles par ordinateur. De manière générale, un support accessible par ordinateur peut inclure un support de stockage non transitoire ou un support de mémoire tel qu'un support magnétique ou optique, par exemple un disque ou un DVD / CD couplé au dispositif informatique 3000 via une interface d'entrée /sortie 3030. Un ordinateur non transitoire un support de stockage accessible peut également inclure tout support volatile ou non volatile tel que la RAM (par exemple, SDRAM, SDRAM DDR, RDRAM, SRAM, etc.), ROM, etc., pouvant être inclus dans certains modes de réalisation du dispositif informatique 3000 en tant que mémoire système. 3020 ou un autre type de mémoire. En outre, un support accessible par ordinateur peut inclure un support de transmission ou des signaux tels que des signaux électriques, électromagnétiques ou numériques, acheminés via un support de communication tel qu'un réseau et / ou une liaison sans fil, tels qu'ils peuvent être mis en œuvre via l'interface de réseau 3040 ou tous les dispositifs informatiques multiples tels que celui illustré à la Fig. 5 peuvent être utilisés pour mettre en œuvre la fonctionnalité décrite dans divers modes de réalisation; Par exemple, des composants logiciels s'exécutant sur différents périphériques et serveurs peuvent collaborer pour fournir la fonctionnalité. Dans certains modes de réalisation, des parties de la fonctionnalité décrite peuvent être mises en œuvre en utilisant des dispositifs de stockage, des dispositifs réseau ou des systèmes informatiques à usage spécifique, en plus ou au lieu d'être mises en œuvre en utilisant des systèmes informatiques à usage général. Le terme "dispositif informatique", tel qu'utilisé ici, fait référence à au moins tous ces types de dispositifs et n'est pas limité à ces types de dispositifs.

Divers modes de réalisation peuvent en outre inclure la réception, l'envoi ou le stockage d'instructions et / ou de données mises en œuvre conformément à la description précédente sur un support accessible par ordinateur. De manière générale, un support accessible par ordinateur peut inclure un support de stockage ou un support de mémoire tel qu'un support magnétique ou optique, par exemple un disque ou un DVD / CD-ROM, un support volatile ou non volatile tel qu'une mémoire vive (SDRAM, DDR, RDRAM, SRAM, etc.). , etc.), ROM, etc., ainsi que des supports de transmission ou des signaux tels que des signaux électriques, électromagnétiques ou numériques, acheminés via un support de communication tel qu'un réseau et / ou une liaison sans fil.

Les divers procédés illustrés sur les figures et décrits ici représentent des exemples de modes de réalisation de procédés. Les procédés peuvent être mis en œuvre dans un logiciel, du matériel ou une combinaison de ceux-ci. L'ordre de la méthode peut être changé et divers éléments peuvent être ajoutés, réorganisés, combinés, omis, modifiés, etc.

Diverses modifications et changements peuvent être apportés, comme cela serait évident pour un homme du métier bénéficiant de cette divulgation. Il est destiné à englober toutes ces modifications et changements et, par conséquent, la description ci-dessus doit être considérée dans un sens illustratif plutôt que restrictif.