FR2780587A1 - Agent de communication entre un administrateur de systeme et un systeme de ressources distribuees et procede de traitement d'une requete sur un attribut multi-instanciable - Google Patents
Agent de communication entre un administrateur de systeme et un systeme de ressources distribuees et procede de traitement d'une requete sur un attribut multi-instanciable Download PDFInfo
- Publication number
- FR2780587A1 FR2780587A1 FR9808057A FR9808057A FR2780587A1 FR 2780587 A1 FR2780587 A1 FR 2780587A1 FR 9808057 A FR9808057 A FR 9808057A FR 9808057 A FR9808057 A FR 9808057A FR 2780587 A1 FR2780587 A1 FR 2780587A1
- Authority
- FR
- France
- Prior art keywords
- request
- attribute
- agent
- specific
- resource
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
Abstract
La présente invention concerne un agent de communication entre un administrateur de système et un système de ressources distribuées et un procédé de traitement d'une requête sur un attribut multi-instanciable d'une ressource.L'agent de communication dans un réseau entre un administrateur et une ressource, le dit réseau comprenant une modélisation de la ressource à gérer contenant les informations nécessaires à la gestion par l'administrateur de la ressource, caractérisé en ce que l'agent de communication utilise pour décentraliser le traitement des requêtes de l'administrateur au niveau de l'agent, une table de requêtes est incluse dans le modèle de la ressource à gérer.
Description
1 2780587
Agent de communication entre un administrateur de système et un système de ressources distribuées et procédé de traitement d'une requête sur un attribut multi-instanciable La présente invention concerne un agent de communication entre un administrateur de système et un système de ressources distribuées et un procédé de traitement d'une requête sur un attribut multi-instanciable d'une ressource. Un tel agent de communication permet à un administrateur de système de commander, surveiller et évaluer, à distance, des ressources
to informatiques.
Il est connu dans l'art antérieur qu'un système informatique distribué est constitué de ressources informatiques qui peuvent être aussi bien, des mainframes, des stations de travail, des ponts, des routeurs, des imprimantes, des systèmes d'exploitation, des applications, etc.,..... En bref, est considérée
comme ressource, toute entité du système informatique.
Administrer ou manager un système distribué, c'est administrer l'ensemble de ses ressources. Pour ce faire, on a recours à une plate- forme d'administration (ou manager) qui doit avoir une vision aussi complète, fine et
détaillée que possible, des ressources qu'elle doit administrer. Cette plate-
forme d'administration peut être très distante des ressources à administrer.
Cette vision d'une ressource est rendue possible grâce à un modèle de la ressource en question. La modélisation d'une ressource s'appuie notamment sur une approche et une structuration des informations en objets comprenant des attributs. Le modèle d'une ressource est géré par un agent capable d'instancier ces objets à l'aide d'informations en provenance de la ressource ou
de la plate-forme d'administration.
Le protocole de communication entre l'administrateur et l'agent le plus répandu est le protocole de gestion de réseau simple (SNMP: Simple Network Management Protocol). Le modèle, utilisé le plus souvent dans le protocole SNMP, est une base d'informations (Management Information Base:MIB)
2 2780587
représentée sous forme d'arbre d'objets concernant la ressource, intégrée à
l'agent sous forme de table.
Lorsque l'administrateur désire respectivement connaître, modifier ou contrôler une information de la MIB, il envoie une requête selon le protocole SNMP à l'agent, qui exécute la requête et fournit en retour à l'administrateur un compte-rendu d'exécution, c'est-à-dire respectivement donne la valeur demandée, accuse réception de la modification et alerte l'administrateur si la
condition de contrôle n'est pas remplie.
Les informations de la ressource représentées par les attributs et to contenues dans la MIB sont de deux types. Soit elles ne peuvent prendre
qu'une seule valeur (ou instance), elles sont alors appelées "attributs mono-
instanciables". Soit elles peuvent prendre une multiplicité de valeur, elles sont alors appelées "attributs multi-instanciables". Lorsque l'administrateur interroge l'agent sur un attribut multi-instanciable, I'administrateur doit procéder à l'envoi d'une requête pour chaque instance souhaitée de l'attribut. Cette nécessité engendre une multiplication du nombre de requêtes sur le réseau existant entre l'administrateur et l'agent entraînant alors une saturation dudit réseau et un coût important. De plus, de manière générale, I'administrateur communique avec l'agent par l'intermédiaire d'un réseau grande distance (Wide Area Network: WAN). Ainsi si la ressource est très distante de l'administrateur, ces
interrogations peuvent prendre beaucoup de temps.
La présente invention a donc pour objet de pallier les inconvénients de l'art antérieur en proposant un agent de communication qui permet de diminuer
le nombre de requêtes sur le réseau et accélérer leur traitement.
Ce but est atteint par le fait que l'agent de communication dans un réseau entre un administrateur et une ressource, ledit réseau comprenant une modélisation de la ressource à gérer contenant les informations nécessaires à la gestion par l'administrateur de la ressource, est caractérisé en ce que l'agent de communication utilise, pour décentraliser le traitement des requêtes de l'administrateur au niveau de l'agent, une table de requêtes incluse dans le
modèle de la ressource à gérer.
3 2780587
Selon une autre particularité, cette table comprenant des attributs déterminés permettant, à partir d'une requête spécifique envoyée par l'administrateur sur un attribut déterminé de la table, de superviser tout ou
partie des instances d'un attribut du modèle de la ressource.
Selon une autre particularité, la table de requête est indexée, et comprend un attribut d'identification de la requête spécifique et des attributs de
configuration des événements qui répondent à la requête spécifique.
Selon une autre particularité, I'index de l'attribut choisi comme index de
la table de requêtes correspond au numéro des requêtes.
Selon une autre particularité, I'attribut d'identification est une formule qui renseigne d'une part, I'attribut du modèle de la ressource sur lequel porte la requête spécifique et d'autre part, la ou les instances interrogées de cet attribut. Selon une autre particularité, la réception d'une requête spécifique par l'agent de communication provoque la création, par l'agent, d'un processus de traitement spécifique (thread) en fonction des instances de la table des requêtes correspondant à l'attribut déterminé compris dans la requête spécifique, ce processus de traitement spécifique effectuant le traitement de la requête spécifique en laissant l'agent libre d'être sollicité, pendant ce temps-là,
par une autre requête de l'administrateur.
Selon une autre particularité, le protocole de communication entre l'administrateur et l'agent est le protocole de gestion de réseau simple (SNMP: Simple Network Management Protocol), et la requête spécifique est une requête de modification d'un objet (SET), I'objet correspondant aux instances déterminées de l'attribut d'identification et de chaque attribut de configuration
de la table de requêtes.
Selon une autre particularité, les requêtes spécifiques sont écrites dans un fichier de scénarios qui est lu par l'agent lors de son démarrage, le contenu de ce fichier de scénarios étant transformé, par l'agent, en au moins
une requête spécifique.
Selon une autre particularité, un fichier de scénarios contenant les éléments nécessaires à l'établissement d'au moins une requête est lu par
4 2780587
l'agent lors de son démarrage, cette lecture provoquant la mise à jour de la table des requêtes et le lancement de chaque requête spécifique
correspondant au contenu du fichier de scénarios.
Selon une autre particularité, chaque requête spécifique est compatible avec le protocole de communication entre l'agent et l'administrateur, et ne
nécessite pas l'arrêt de l'agent lors de l'interrogation d'un attribut multi-
instanciable. Un deuxième but de l'invention est de proposer un procédé permettant
le traitement décentralisé des requêtes sur des attributs multiinstanciables.
Io Ce but est atteint par le fait que le procédé de traitement d'une requête d'un administrateur, sur un attribut multi-instanciable par un agent de communication comprend: - une première étape d'envoi d'une requête spécifique par l'administrateur vers un agent de communication sur au moins un attribut déterminé d'une table de requêtes incluse dans le modèle de la ressource géré par l'agent de communication, - une deuxième étape de détection de la requête spécifique par l'agent de communication et de vérification de la disponibilité de la ressource, pour faire créer par l'agent un processus de traitement spécifique (thread) à partir du ou des attributs déterminés de la requête spécifique de l'administrateur, dans le cas de disponibilité de la ressource ou pour faire mettre en attente la
requête par l'agent jusqu'à ce que la ressource devienne disponible.
Selon une autre particularité, le procédé comprend une troisième étape de comptage du nombre d'index du modèle de la ressource par le processus de traitement spécifique et de création ou de mise à jour d'une base de
données locale.
Selon une autre particularité, le procédé comprend une quatrième étape de renseignement sur la base de données locales par le processus de
traitement spécifique en interrogeant la ressource par l'intermédiaire de l'agent.
Selon une autre particularité, le procédé comprend une cinquième étape o le processus de traitement spécifique réalise le traitement correspondant aux instances des attributs de la requête spécifique, en fonction
2780587
des instances recueillies sur la ressource et construit une réponse pour
l'administrateur en fonction du résultat du traitement.
Selon une autre particularité, le procédé comprend une sixième étape o le processus de traitement spécifique se met en attente pendant une durée déterminée par la requête spécifique de l'administrateur, puis exécute la
troisième étape.
D'autres particularités et avantages de la présente invention
apparaîtront plus clairement à la lecture de la description ci-après faite en
référence aux dessins annexés, dans lesquels: - la figure 1A représente un schéma des relations qui existent entre un
administrateur, un agent et une ressource d'un système informatique.
- la figure 1 B représente un exemple de base d'information (MIB) pour
un agent gérant les utilisateurs d'un système.
- la figure 2 représente un diagramme du mode d'interrogation d'un
agent de l'art antérieur par un administrateur.
- la figure 3 représente un diagramme du mode d'interrogation d'un
attribut multi-instanciable d'un agent, selon l'invention, par un administrateur.
- la figure 4 représente un diagramme du mode de fonctionnement d'un
traitement spécifique (thread).
Pour mieux comprendre l'objet et l'intérêt de l'invention qui va être
décrite, un certain nombre de définitions sont nécessaires.
La figure 1A représente un schéma des relations qui existent entre un administrateur (20), un agent (10) et une ressource (30) d'un système à administrer. Un administrateur (20) de système informatique est un service qui tourne sur un matériel informatique (2) d'un système et qui doit être capable de superviser l'ensemble des différentes ressources (30) du système et cela bien que les ressources soient situées à distance. Pour cela, I'administrateur ne fait pas directement appel à la ressource à administrer, mais utilise un modèle (21) de cette ressource qui est représenté sous forme d'arbre d'objets (MIB). Un objet géré possède des propriétés, à savoir des attributs, des actions qu'il peut exécuter, des notifications et un comportement qu'il a en réponse aux
sollicitations externes.
Le fonctionnement d'un agent est le suivant. Dans une vision très schématique, on peut découper un agent en couches standards de communication, en couches amenant des facilités pour encoder et décoder des
syntaxes, et manipuler des objets.
Les objets (ou quanta d'information) sont disponibles à travers ce qu'on appelle "une base d'information" (MIB:Management Information Base) qui est en quelque sorte une base de données virtuelle modélisant la ressource à
administrer. Par abus de langage, on dit souvent qu'un agent gère une MIB.
Afin de faciliter l'accès aux objets (ou informations) de la MIB, les objets multi-
1o instanciables sont rangés dans une table, avec leurs attributs. Les colonnes de cette table sont également indexées. L'index est un attribut qui permet d'identifier les différentes instances de cet objet. Les autres attributs de la colonne de la table correspondant à l'index, fournissent différentes caractéristiques de l'attribut (ou objet) indexé. A titre d'exemple, prenons un t5 agent qui gère les utilisateurs (objets) d'un système. La colonne de la table utilisée par cet agent, représentée figure 1 B, comprend comme index l'attribut " Nom ". Les instances de cet attribut correspondent aux noms des utilisateurs du système. Les autres lignes de la colonne correspondent aux caractéristiques des utilisateurs. Ainsi, la colonne peut comporter un attribut " mot de passe ", un attribut " nombre d'accès ", et d'autres attributs caractérisant les utilisateurs. Chacun de ces attributs prend une valeur (ou
instance) différente pour chaque nom d'utilisateur (instance).
Un agent contient aussi et avant tout: - du code pour gérer le modèle d'administration de la ressource à administrer, appelé "noyau protocolaire"; - de l'expertise sur la ressource sous forme d'automates (suivant la
richesse du modèle géré par l'agent).
Ainsi à chaque ressource à administrer, sont donc associés du code et
de l'expertise spécifiques.
Afin de fixer les idées sur les différentes opérations réalisables par un administrateur sur un agent, nous prendrons comme exemple, non limitatif de protocole de communication, le protocole de gestion de réseau simple (SNMP:
7 2780587
Simple Network Management Protocol). Les opérations disponibles à travers le protocole de communication SNMP et permettant d'une part, à l'agent de manipuler les objets de la MIB qu'il gère, et d'autre part, à l'administrateur de superviser une ressource, sont les suivantes: lecture d'un objet (get) - lecture de l'objet suivant (get- next) écriture d'un objet (set) - opérations d'alerte (trap) Précisons encore que, plutôt que les objets, qui sont en fait des io canevas (templates), ce sont les instances de ces objets qui sont manipulées
par le protocole SNMP, c'est-à-dire les instances des attributs.
Pour instancier les objets de la MIB qu'il gère, un agent doit aller chercher les informations directement dans la ressource physique par le biais de méthodes (API: Application Programming Interface), qui sont des procédures associées à un objet particulier, déclenchées à chaque fois que l'on désire réaliser une opération sur l'objet en question. Ce sont par ces méthodes que les instances de la MIB prennent une valeur sémantique: selon la manière avec laquelle on ira chercher dans la ressource physique la valeur
d'une instance, cette instance aura tel ou tel sens, telle ou telle fonction.
Suivant le type d'objet de la MIB, I'attribut prend une seule et unique valeur (instance), I'attribut est alors mono-instanciable, ou l'attribut prend plusieurs valeurs, l'attribut est alors multi-instanciable. Dans l'exemple de l'agent gérant, les utilisateurs d'un système et tous les attributs sont multi-instanciables. En
effet, chaque attribut a une instance par utilisateur.
La figure 2 représente un diagramme du mode d'interrogation d'un agent, gérant les utilisateurs d'un système, de l'art antérieur par un administrateur. Pour faciliter la consultation des différentes instances, I'agent (10) mémorise, par exemple dans une zone mémoire (110) appelé "cache", l'ensemble des indexes de toutes les tables du modèle de la ressource, par exemple, la table utilisateur (fig. 1 B). De plus, I'agent (10) effectue une mise à jour périodique de ce cache (110) en allant chercher les valeurs des différents indexes dans la ressource, grâce aux méthodes (API). La période de mise à
8 2780587
jour est déterminée par l'utilisateur. Lorsque l'administrateur veut consulter un attribut multi-instanciable, la requête, (40) qu'il transmet à l'agent (10), doit comporter l'attribut recherché, suivi de l'identification de l'instance. Dans l'exemple précédent d'un agent gérant les utilisateurs d'un système, la requête (40) consistant, par exemple à rechercher le nombre d'accès (" NbreDeLogin ") d'un utilisateur déterminé, s'appelant par exemple " userO " sera rédigée de la façon suivante: " get(NbreDeLogin.userO) ". Si à présent l'administrateur (20) souhaite connaître tous les utilisateurs qui se sont connectés (logged in) plus de 10 fois sur le système, il devra connaître la
l0 valeur de l'attribut " NbreDeLogin " de tous les utilisateurs du système.
L'administrateur doit dans un premier temps envoyer une requête (GetNext) pour connaître toutes les instances de l'attribut " Nom ". La réponse de l'agent fournit alors tous les noms des utilisateurs, ce qui permet d'identifier les N indexes de cet attribut:user0, user1, user2,... , userN. Puis, I'administrateur doit envoyer, pour chaque nom d'utilisateurs, fournis par l'agent, une requête de consultation (Get) sur l'attribut " nombre d'accès ", get(NbreDeLogin.userO) get(NbreDeLogin.userl),..., get(NbreDeLogin.userN). Ainsi, si N est le nombre d'utilisateurs de la ressource, I'administrateur doit envoyer N requête de consultation du nombre d'accès. Comme, nous l'avons expliqué dans l'état de l'art antérieur, I'administrateur communique avec l'agent par un réseau à grandes distances (WAN; Wide Area Network). Or, les communications sur ce type de réseau sont coûteuses en terme de temps. De plus, la multiplication
des requêtes surcharge le réseau, diminuant alors ses performances.
La figure 3 représente un diagramme du mode d'interrogation par un administrateur, d'un attribut multi-instanciable d'un agent gérant les utilisateurs d'un système, selon l'invention. La présente invention consiste donc à décentraliser, au niveau de l'agent (10), le traitement (12, 13, 14) d'une requête (31) portant sur un attribut multiinstanciable. En effet, I'agent (10) communique avec la ressource (30) administrée par l'administrateur (20) par un réseau local (LAN: Local Area Network) qui est plus fiable et plus rapide que le WAN. Pour cela, I'agent (10) est capable de reconnaître une requête (31) spécifique de supervision d'un attribut multi-instanciable, tout en
respectant le protocole de communication de l'administrateur (20).
A cet effet, I'agent (10) comprend, dans son modèle (fig. lB) de la ressource, une table de requêtes (fig. 1C) qui formalise chaque requête (31) spécifique de supervision des attributs multi-instanciables, envoyées par l'administrateur (20). Cette table comprend le formalisme des requêtes (31) spécifiques de traitement des attributs multi- instanciables envoyées par l'administrateur. Comme toutes les tables du modèle, la table des requêtes est indexée. L'attribut choisi comme index, correspond au numéro de la requête io attribué par l'utilisateur. Outre cet attribut indexé, la table de requête comprend un attribut d'identification de la requête et au moins un attribut de configuration des événements qui répondent à la requête. L'attribut d'identification est une formule qui permet d'identifier la requête envoyée par l'administrateur. Cette formule permet non seulement d'identifier l'attribut de la ressource sur lequel i5 porte la requête, mais également d'identifier la ou les instances particulières qui doivent être interrogées. Cette formule se présente sous la forme de deux chaînes de caractères séparé par ": ". La première chaîne de caractères identifie l'attribut du modèle de la ressource concerné par la requête. La deuxième chaîne de caractères est constituée de la liste des instances devant être interrogées, chaque instance de la liste est séparée par le caractère espace. Si la requête (31) concerne toutes les instances de l'attribut identifié par la première chaîne de caractères, la liste des instances est remplacée par
le caractère " * ".
Le ou les attributs de configuration des événements qui répondront à la requête spécifique (31) sont en fait destinés à identifier l'opération à effectuer sur les instances interrogées. Ces opérations sont, en règle générale, des opérations de contrôle qui déclenchent l'envoi d'une alarme, soit vers le système, soit vers l'administrateur (20). Le ou les attributs de configuration vont donc consister à configurer l'alarme. Cette configuration consiste notamment à déterminer quelle va être la condition de déclenchement d'alarme, vers qui (système ou manager) va être envoyée l'alarme, quelle est la périodicité du contrôle, quel niveau d'alerte est envoyé, et combien de fois la condition doit
2780587
se réaliser pour déclencher l'alarme. Le formalisme utilisé pour configurer l'alarme est, par exemple, le suivant:
L'attribut " période " correspond à la périodicité du contrôle.
L'attribut " seuil ", (comparisonValue) correspond à la valeur qui va être comparée à l'attribut déterminé dans la requête spécifique. L'attribut " élément de comparaison " (comparisonType) correspond à l'opération booléenne (<, >, =, É) effectuée entre le seuil et chaque instance de
l'attribut de la requête spécifique.
L'attribut " eventlog " correspond à la direction de l'alarme.
[0 L'attribut " sévère " (severity) correspond au niveau de gravité de l'alarme. L'attribut " répété " (repeat) correspond au nombre de fois o la condition, définie par la comparaison du seuil avec chaque instance de
l'attribut déterminé, doit se réaliser pour déclencher l'envoi de l'alarme.
La table de requête comprend toujours les mêmes attributs quelles que soient les requêtes (31) spécifiques, puisque ces attributs représentent le formalisme de la requête spécifique. Seules les instances de ces attributs
varient d'une requête à l'autre.
Grâce à cette table de requêtes, il est possible de construire une seule requête (31) spécifique pour l'interrogation d'un attribut multiinstanciable, au lieu d'une requête par instance de l'attribut multiinstanciable. Puisque cette requête est conforme au protocole de communication de l'agent, celui-ci pourra la détecter. Grâce à l'existence de la table des requêtes et à des moyens appropriés, il pourra également reconnaître le formalisme particulier de la requête spécifique envoyée par l'administrateur et exécuter le traitement de ladite requête. Notamment, l'agent, selon l'invention, est capable de détecter la formule ":* " dans la requête spécifique qui correspond à une requête
d'interrogation de toutes les instances d'un attribut déterminé.
Pour illustrer le formalisme de la requête spécifique envoyée par lI'administrateur, reprenons l'exemple précédent, de l'agent gérant les utilisateurs d'un système sachant que, dans l'exemple, le protocole utilisé est le protocole SNMP. Une requête (31) spécifique peut, par exemple, consister à il 2780587 comptabiliser, toutes les 5 minutes, les utilisateurs qui se sont connectés plus de 10 fois sur le système, et d'envoyer une alarme de niveau déterminé, vers l'administrateur si plus de deux utilisateurs sont connectés plus de dix fois. A partir d'une application d'interface homme-machine dite " ISM Monitor ", I'utilisateur administrateur configure les attributs de la requête dont le formalisme est le suivant: snmpset Alarmetable identification de la table de requête ( début de la requête formule=NombreDeLogin:* identification de la requête, ici l'administrateur souhaite interroger toutes les instances de l'attribut " NombreDeLogin ", qui est l'attribut dont les instances représentent le nombre de
connexion d'un utilisateur.
Period=300 Périodicité de la comparaison: toutes les 300 secondes (5min) ComparisonType> I'opération de contrôle est supérieure ComparisonValue=10 la valeur avec laquelle seront comparées les instances de l'attribut " NombreDeLogin " est 10 Evenlog=false Lorsque Evenlog prend la valeur " false " cela signifie que l'alarme est envoyée vers l'administrateur. Lorsque Evenlog prend la valeur " true ", I'alarme est envoyée dans un fichier du système. Severity=Warning le niveau de l'alarme est " warning ", ce qui
correspond à une simple notification.
Repeat=2 la condition " NombreDeLogin>10 " doit se
répéter 2 fois pour que l'alarme soit déclenchée.
)_ fin de la requête La requête (31) spécifique consiste donc à écrire (Set) les différents
attributs dans une table de requête " alarme, pour tous les utilisateurs.
12 2780587
La réception d'une requête spécifique détectée par l'agent (10) par la présence de la formule " * ", provoque un comportement particulier de celui-ci, qui déclenche un premier traitement spécifique (12.1) (thread) dont le déroulement est représenté figure 4. Comme nous venons de l'expliquer, puisque la requête (31) spécifique est conforme au protocole de communication de l'agent, celui-ci détecte qu'il s'agit d'une requête spécifique grâce au formalisme particulier de ladite requête et, au fait que la commande de la requête est une écriture (SET) des instances de la table des requêtes (14.1). L'agent (10) crée alors, à partir des instances des attributs fournis dans to la requête spécifique (31.1), un processus (12.1) de traitement spécifique (thread) de la requête qui crée une base de données locale (14.1), stockée dans une zone mémoire ou dans un fichier, dans laquelle il stocke des informations de mise à jour. Avantageusement, le processus (12) de traitement spécifique permet non seulement à l'agent d'exécuter les opérations nécessaires au traitement de la requête, mais également n'empêche pas l'agent d'être interrogé sur une autre requête (31.k) de l'administrateur. Le traitement (12, 13, 14) de la requête spécifique nécessite l'utilisation du cache (110) usuel mémorisé par l'agent qui regroupe tous les indexes du modèle de la ressource. Ainsi, pour éviter que le cache ne soit modifié par une autre requête (15) pendant le traitement (12, 13, 14) de la requête (31.1) spécifique, le processus (12.1) de traitement spécifique positionne (126, fig. 4), dès que le cache (110) usuel est disponible, un sémaphore (13) (flag) associé à l'index de l'attribut concerné par la requête spécifique (31.1) indiquant à l'agent (10) que le cache (110) usuel n'est plus disponible. Ainsi si, pendant l'exécution de traitement (12, 13, 14) de la première requête spécifique (31.1), I'agent (10) reçoit une autre requête (31.2), celui-ci va consulter si le sémaphore (13) indiquant que le cache n'est pas disponible est présent, et dans l'affirmative met la deuxième requête (31.2) en attente jusqu'à ce que le sémaphore (13)
soit retiré.
La première opération du processus (12.1) de traitement spécifique consiste à compter (120, fig. 4) et identifier dans le cache (110), les indexes correspondant à l'attribut spécifié dans la requête spécifique, puis à créer (121, fig. 4) une base de données (14.1) locale contenant les indexes qui viennent d'être comptés et identifiés ainsi que les valeurs des différents attributs de la requête spécifique (31.1), par exemple les valeurs des attributs Period, comparisonType, ComparaisonValue, Evenlog, Severity et repeat. Ensuite, le processus de traitement spécifique (12.1) renseigne (121, fig. 4) cette base de données (14.1) en allant chercher sur la ressource, par des moyens connus, tels qu'une API, les instances spécifiées dans la requête (31.1) spécifique. Une fois cette base de données (14.1) renseignée, le processus de traitement spécifique (12.1) créé par l'agent (12) effectue le traitement (122, fig. 4) i0 proprement dit de la requête spécifique (31), correspondant aux conditions paramétrées dans la requête spécifique. La réponse (123, fig. 4) de l'agent (10) à la requête spécifique (31.1) de l'administrateur dépend du résultat du traitement. Enfin, le processus se met en attente (124, fig. 4) pendant une
durée égale à la période de contrôle paramétrée dans la requête spécifique. i5 Lorsque cette période s'achève, le processus de traitement spécifique
(12.1) renouvelle le traitement de la requête par la première opération, en ayant préalablement vérifié (125, fig. 4) que le cache (110) soit disponible. On constate que dès qu'une requête (31.1) spécifique est envoyée à l'agent (10), le contrôle, formalisé dans la requête spécifique, s'effectuera à intervalle de temps régulier correspondant à une instance de l'attribut " période ". Le protocole SNMP permet de supprimer des attributs d'une table du modèle géré par l'agent. Ainsi pour supprimer l'effet d'une requête (31.1) spécifique, il suffit d'envoyer à l'agent une requête de suppression ayant comme attribut
l'identification de la requête à supprimer.
Pour illustrer les opérations effectuées par le processus de traitement spécifique créé par l'agent, reprenons l'exemple précédent. La requête (31.1) spécifique décrite dans l'exemple, concerne la surveillance du nombre d'accès de tous les utilisateurs. Après avoir positionné le sémaphore (13) et consulté le cache (110) de l'agent, I'agent lance le processus (12.1) de traitement spécifique (thread) crée une base de données (14.1) locale comprenant une première colonne constituée de tous les noms d'utilisateurs: userO, user1,..., userN, puisque l'index de la table utilisateur est l'attribut " Nom ". Après que le
14 2780587
processus (12.1) de traitement ait consulté la ressource, la base de donnée comprend une deuxième colonne correspondant au nombre d'accès (NbrDeLogin) de chaque utilisateur créée par le processus (12.1) et renseignée par ce dernier. A ce stade, le processus (12.1) de traitement spécifique effectue le traitement de la requête, consistant à comparer la valeur du nombre d'accès avec le seuil qui est égale à 10. Chaque fois que la condition correspondant à la requête spécifique est réalisée, c'est-à-dire dans l'exemple, chaque fois que le nombre d'accès est supérieur à 10, le processus de traitement spécifique ajoute 1 à un compteur mémoriser dans une zone
1o mémoire ou un fichier, par exemple, dans la base de données locale (14.1).
Lorsque tous les nombres d'accès ont été comparés, le processus (12.1) de traitement consulte le compteur, et si la valeur du compteur est supérieure ou égale à 2 (correspondant à la valeur de l'attribut " repeat "), le processus (12.1) de traitement envoie vers l'administrateur, conformément à la configuration de l'alarme, une notification (trap) indiquant les noms des utilisateurs dont le nombre d'accès est supérieur à 10. Puis, le processus (12.1) de traitement se met en attente pendant une durée de 5 minutes avant
de renouveler l'opération de contrôle.
L'utilisation de requêtes spécifiques qui sont compatibles avec le protocole de communication entre l'agent et l'administrateur, ne nécessite pas
que l'agent soit arrêté pour effectuer une interrogation sur un attribut multi-
instanciable. Il suffit que celui-ci possède la table des requêtes et soit construit au départ avec les moyens nécessaires pour détecter le formalisme d'une requête spécifique et créer le processus de traitement spécifique. Cependant pour qu'une même requête spécifique soit exécutée sur plusieurs systèmes, celle-ci doit être envoyée à chaque agent correspondant à partir de l'administrateur. Pour éviter de répéter l'envoi d'une même requête spécifique vers un nombre déterminé d'agents, un fichier de scénarios est lu par les différents agents des systèmes administrés par un administrateur, lors du démarrage de chaque agent. Ce fichier de scénario est créé par l'administrateur et l'agent est configuré pour lire ce fichier lors de son démarrage. Ce fichier de scénarios contient tous les éléments nécessaires à
2780587
l'établissement d'au moins une requête. c'est-à-dire, pour chaque requête spécifique, une instance pour un attribut d'identification et au moins une instance pour un attribut de configuration des événements. Avantageusement, ce fichier est un fichier texte o une ligne comprend le nom d'un attribut de la table des requêtes suivi de la valeur de l'instance de cet attribut pour une requête spécifique déterminée. Il est possible de mémoriser sous cette forme plusieurs requêtes spécifiques en séparant dans le fichier texte chaque requête par une ligne vierge. Un exemple de fichier de scénarios est fourni à l'annexe 1. Comme nous venons de l'expliquer, ce fichier est lu par l'agent lors de son démarrage. Lorsque l'agent lit le fichier, qui lorsqu'il détecte le formalisme particulier de ce fichier, renseigne la table des requêtes et transforme ainsi le contenu du fichier de scénarios en requête spécifique sur la détection de la formule ":* ". Ainsi, dès que le démarrage est achevé, les requêtes écrites dans le fichier de configuration sont immédiatement traitées par le lancement des processus de traitement spécifique (thread) correspondant, sans que l'utilisateur ne soit obligé de saisir toutes ces
requêtes spécifiques par l'intermédiaire de l'administrateur.
On conçoit que l'agent selon l'invention et le procédé de traitement d'une requête sur un attribut multi-instanciable permet de déplacer le travail de traitement de la requête au niveau du réseau local (LAN). En effet, une seule requête (la requête spécifique) est envoyée sur le réseau grande distance (WAN), puis, I'agent réagit en effectuant sur le réseau local le traitement de la requête portant sur un attribut multi- instanciable. Ainsi, le réseau grande
distance est moins surchargé.
Il est clair que d'autres modifications à la portée de l'homme du métier entrent dans le cadre de l'invention. Notamment, il est à la portée de l'homme de métier d'appliquer la présente invention à tout type de protocole de communication entre un administrateur et un agent, et à tout type d'agent
permettant à un administrateur d'administrer des ressources.
16 2780587
ANE" 1
ntWkgpAlarmFormula ntWkgpUsrFlagsAccountDisable:* ntWkgpAlarmPeriod 1800 ntWkgpAlarmComparisonType > ntWkgpAlarmComparisonValue 0 ntWkgpAlarmRepeat 0 ntWkgpAlarmSeverity warning ntWkgpAlarmOnce false ntWkgpAlarmEventLog true ntWkgpAlarmProgram none ntWkgpAlarmTDate 1997/09/19-09:16:21 ntWkgpAlarmClearValue default ntWkgpAlarmcheckPeriod 0 ntWkgpAlarmFormula ntWkgpUsrFlagsAccountLockout: * ntWkgpAlarmPeriod 1800 ntWkgpAlarmComparisonType > ntWkgpAlarmCompari sonValue 0 ntWkgpAlarmRepeat 0 ntWkgpAlarmSeverity warning ntWkgpAlarmOnce false ntWkgpAlarmEventLog true ntWkgpAlarmProgram none ntWkgpAlarmDate 1997/09/19-09:16:21 ntWkgpAlarmClearValue default ntWkgpAlarmCheckPeriod 0 ntWkgpAlarmFormula ntWkgpUsrLogonBadPasswdCount:* ntWkgpAlarmPeriod 1800 ntWkgpAlarmComparisonType > ntWkgpAlarmComparisonValue 0 ntWkgpAlarmRepeat 5 ntWkgpAlarmSeverity major ntWkgpAlarmOnce false ntWkgpAlarmEventLog false ntWkgpAlarmProgram none ntWkgpAlarmDate 1997/09/19-09:16:21 ntWkgpAlarmClearValue default ntWkgpAlarmCheckPeriod 0 ntWkgpAlarmFormula ntWkgpUsrFlagsPasswdNotReqd: * ntWkgpAlarmPeriod 1800 ntWkgpAlarmComparisonType > ntWkgpAlarmComparisonValue 0 ntWkgpAlarmRepeat 0 ntWkgpAlarmSeverity warning ntWkgpAlarmOnce false ntWkgpAlarmEventLog false ntWkgpAlarmProgram none ntWkgpAlarmDate 1997/09/19-09:16:21 ntWkgpAlarmClearValue default ntWkgpAlarmCheckPeriod 0 ntWkgpAlarmFormula ntWkgpUsrLogonNumLogons: * ntWkgpAlarmPeriod 1800 ntWkgpAlarmComparisonType < ntWkgpAlarmComparisonValue 10 ntWkgpAlarmRepeat 0 ntWkgpAlarmseverity warning ntWkgpAlarmOnce false ntWkgpAlarmEventLog true ntWkgpAlarmProgram none
17 2780587
ntWkgpAlarmDate 1997/09/19-09:16:21 ntWkgpAlarmClearValue default ntWkgpAlarmCheckPeriod O ntWkgpAlarmFormula ntWkgpUsrIdAdminPriv:Guest ntWkgpAlarmPeriod 600 ntWkgpAlarmComparisonType > ntWkgpAlarmComparisonValue O ntWkgpAlarmRepeat O ntWkgpAlarmSeverity severe ntWkgpAlarmOnce false ntWkgpAlarmEventLog false ntWkgpAlarmProgram none ntWkgpAlarmDate 1997/09/19-09:16:21 ntWkgpAlarmClearValue default ntWkgpAlarmCheckPeriod O ntWkgpAlarmFormula ntWkgpUsrIdUsrPriv:Guest ntWkgpAlarmPeriod 600 ntWkgpAlarmComparisonType > ntWkgpAlarmComparisonValue O ntWkgpAlarmRepeat O ntWkgpAlarmSeverity warning ntWkgpAlarmOnce false ntWkgpAlarmEventLog false ntWkgpAlarmProgram none ntWkgpAlarmDate 1997/09/19-09:16:21 ntWkgpAlarmClearValue default ntWkgpAlarmCheckPeriod O ntWkgpAlarmFormula ntWkgpUsrLogonNumLogons:Guest ntWkgpAlarmPeriod 600 ntWkgpAlarmComparisonType > ntWkgpAlarmComparisonValue 50 ntWkgpAlarmRepeat O ntWkgpAlarmSeverity severe ntWkgpAlarmOnce false ntWkgpAlarmEventLog false ntWkgpAlarmProgram none ntWkgpAlarmDate 1997/09/19-09:16:21 ntWkgpAlarmClearValue default ntWkgpAlarmCheckPeriod O ntWkgpAlarmFormula ntWkgpUsrFlagsPasswdNotReqd:Administrator ntWkgpAlarmPeriod 600 ntWkgpAlarmComparisonType > ntWkgpAlarmComparisonValue O ntWkgpAlarmRepeat O ntWkgpAlarmSeverity severe ntWkgpAlarmonce false ntWkgpAlarmEventLog false ntWkgpAlarmProgram none ntWkgpAlarmDate 1997/09/19-09:16:21 ntWkgpAlarmClearValue default ntWkgpAlarmCheckPeriod O ntWkgpAlarmFormula ntWkgpUsrIdPasswdExpired:Administrator ntWkgpAlarmPeriod 1800 ntWkgpAlarmComparisonType > ntWkgpAlarmComparisonValue O ntWkgpAlarmRepeat O O p OadeXatpqD5laMelyfimu 2 Inst ep anI eAe I DULI Y5[M; U ITZ:91:606t/60/L66t aeC2IteVd5yM5 u auou ueO:od=t-Vd5XM=lu eSl; bOrqUIAMUIyVdJ5XM2U eSTJ6UOLe;d)( E sUe8muou1Id- u Lu9uaL 2I=eASueydJS2
Claims (15)
1. Procédé de traitement de requêtes d'un administrateur vers un agent s de communication portant sur au moins une ressource, chaque ressource étant représentée par un modèle contenant les informations nécessaires à la gestion par l'administrateur de la ressource, le modèle étant géré par l'agent de communication, caractérisé en ce qu'il consiste à décentraliser le traitement des requêtes au niveau de l'agent de communication à l'aide d'une unique requête spécifique de l'administrateur vers l'agent, la requête spécifique étant formalisée dans une table de requêtes incluse dans le modèle de la ressource
à gérer.
2. Procédé selon la revendication 1, caractérisé en ce qu'il consiste à superviser tout ou partie des instances d'un attribut du modèle de la ressource à partir de la requête spécifique envoyée par l'administrateur, la requête
portant sur au moins un attribut déterminé contenu dans la table de requêtes.
3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce
qu'il consiste à identifier la requête spécifique à l'aide d'un attribut d'identification compris dans la table de requêtes permettant d'identifier d'une part, I'attribut du modèle de la ressource sur lequel porte la requête spécifique et d'autre part, la ou les instances interrogées dudit attribut du modèle de la ressource.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il
consiste à identifier une opération à effectuer sur les instances de l'attribut interrogées à l'aide d'au moins un attribut de configuration contenu dans la
table de requêtes.
5. Procédé selon les revendications 3 et 4, caractérisé en ce qu'il
consiste à utiliser comme protocole de communication entre l'administrateur et l'agent, le protocole de gestion de réseau simple (SNMP: Simple Network Management Protocol), et comme requête spécifique, une requête de modification d'un objet (SET), I'objet correspondant aux instances déterminées de l'attribut d'identification et de chaque attribut de configuration de la table de requêtes.
6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'il
consiste à répertorier la table de requêtes à l'aide d'un index comme table du modèle de la ressource et à choisir comme index un attribut correspondant au
numéro de la requête spécifique correspondante.
7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'il
consiste à écrire au moins une requête spécifique dans un fichier de scénarios qui est lu par l'agent lors de son démarrage, le contenu de ce fichier de
scénarios étant transformé, par l'agent, en au moins une requête spécifique.
8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'il
consiste à la réception d'une requête spécifique par l'agent de communication, à provoquer, dans une première étape, la création, par l'agent, d'un processus de traitement spécifique (thread) de la requête spécifique en fonction de la table des requêtes correspondante, ce processus de traitement spécifique effectuant le traitement de la requête spécifique en laissant l'agent libre d'être
sollicité pendant ce temps-là par une autre requête de l'administrateur.
9. Procédé selon les revendications 6 et 8, caractérisé en ce qu'il
consiste, dans une deuxième étape, à positionner, à l'aide du processus de traitement spécifique, dès que des moyens de mémorisation regroupant tous les indexes du modèle de la ressource sont disponibles, un sémaphore (13) indiquant à l'agent que les moyens de mémorisation ne sont plus disponibles
pendant le traitement de la requête spécifique.
10. Procédé selon les revendications 8 et 9, caractérisé en ce qu'il
consiste, dans une troisième étape, à l'aide du processus de traitement spécifique, à compter et à identifier les indexes correspondant à l'attribut spécifié dans la requête spécifique et à créer ou mettre à jour une base de
données locale.
11. Procédé selon la revendication 10, caractérisé en ce qu'il consiste, dans une quatrième étape, à l'aide du processus de traitement spécifique, à renseigner la base de données locale en interrogeant la ressource par
l'intermédiaire de l'agent.
12. Procédé selon la revendication 11, caractérisé en ce qu'il consiste, dans une cinquième étape, à l'aide du processus de traitement spécifique, à réaliser le traitement correspondant à la requête spécifique, en fonction des informations recueillies sur la ressource et à construire une réponse pour l'administrateur en fonction du résultat du traitement.
13. Procédé selon la revendication 12, caractérisé en ce qu'il consiste, dans une sixième étape, à mettre en attente le processus de traitement spécifique pendant une durée déterminée par la requête spécifique de l'administrateur puis à exécuter la deuxième, troisième, quatrième et cinquième étape.
14. Utilisation du procédé selon l'une des revendications 1 à 13 pour le
traitement d'une requête sur un attribut multi-instanciable.
15. Système informatique pour la mise en oeuvre du procédé selon
l'une des revendications 1 à 14.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9808057A FR2780587B1 (fr) | 1998-06-25 | 1998-06-25 | Agent de communication entre un administrateur de systeme et un systeme de ressources distribuees et procede de traitement d'une requete sur un attribut multi-instanciable |
| EP99957215A EP1048144A2 (fr) | 1998-06-25 | 1999-06-25 | Agent de communication entre un administrateur de systeme et un systeme de ressources distribuees et procede de traitement d'une requete sur un attribut |
| PCT/FR1999/001536 WO1999067908A2 (fr) | 1998-06-25 | 1999-06-25 | Agent de communication entre un administrateur de systeme et un systeme de ressources distribuees et procede de traitement d'une requete sur un attribut multi-instanciable |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9808057A FR2780587B1 (fr) | 1998-06-25 | 1998-06-25 | Agent de communication entre un administrateur de systeme et un systeme de ressources distribuees et procede de traitement d'une requete sur un attribut multi-instanciable |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2780587A1 true FR2780587A1 (fr) | 1999-12-31 |
| FR2780587B1 FR2780587B1 (fr) | 2004-06-04 |
Family
ID=9527848
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR9808057A Expired - Fee Related FR2780587B1 (fr) | 1998-06-25 | 1998-06-25 | Agent de communication entre un administrateur de systeme et un systeme de ressources distribuees et procede de traitement d'une requete sur un attribut multi-instanciable |
Country Status (3)
| Country | Link |
|---|---|
| EP (1) | EP1048144A2 (fr) |
| FR (1) | FR2780587B1 (fr) |
| WO (1) | WO1999067908A2 (fr) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0621705A2 (fr) * | 1993-03-22 | 1994-10-26 | International Business Machines Corporation | Procédé pour réduire le flux de messages d'instrumentation "SNMP" |
-
1998
- 1998-06-25 FR FR9808057A patent/FR2780587B1/fr not_active Expired - Fee Related
-
1999
- 1999-06-25 EP EP99957215A patent/EP1048144A2/fr not_active Withdrawn
- 1999-06-25 WO PCT/FR1999/001536 patent/WO1999067908A2/fr not_active Application Discontinuation
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0621705A2 (fr) * | 1993-03-22 | 1994-10-26 | International Business Machines Corporation | Procédé pour réduire le flux de messages d'instrumentation "SNMP" |
Non-Patent Citations (3)
| Title |
|---|
| BAKTHA MURALIDHARAN: "MULTIPROTOCOL MANAGEMENT AGENTS: A LOOK AT AN IMPLEMENTATION AND THE ISSUES TO CONSIDER", IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, vol. 11, no. 9, 1 December 1993 (1993-12-01), pages 1336 - 1345, XP000491491 * |
| MAGEDANZ T ET AL: "INTELLIGENT AGENTS AN EMERGING TECHNOLOGY FOR NEXT GENERATION TELECOMMUNICATIONS?", PROCEEDINGS OF IEEE INFOCOM 1996. CONFERENCE ON COMPUTER COMMUNICATIONS, FIFTEENTH ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER AND COMMUNICATIONS SOCIETIES. NETWORKING THE NEXT GENERATION SAN FRANCISCO, MAR. 24 - 28, 1996, vol. 2, no. CONF. 15, 24 March 1996 (1996-03-24), INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, pages 464 - 472, XP000621308 * |
| SCHONWALDER J: "Network management by delegation - From research prototypes towards standards", COMPUTER NETWORKS AND ISDN SYSTEMS, vol. 29, no. 15, November 1997 (1997-11-01), pages 1843-1852, XP004099486 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO1999067908A3 (fr) | 2000-03-16 |
| WO1999067908A2 (fr) | 1999-12-29 |
| EP1048144A2 (fr) | 2000-11-02 |
| FR2780587B1 (fr) | 2004-06-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11343268B2 (en) | Detection of network anomalies based on relationship graphs | |
| EP0820013B1 (fr) | Procédé de surveillance en temps réel d'un système informatique pour son administration et l'aide à sa maintenance en phase d'exploitation | |
| EP3479285B1 (fr) | Procédé et dispositif de surveillance de la sécurité d'un système d'information | |
| EP1695485B1 (fr) | Procede de classification automatique d un ensemble d a lertes issues de sondes de detection d intrusions d un systeme de securite d information | |
| EP2832069B1 (fr) | Systeme de supervision de la securite d'une architecture | |
| US7610377B2 (en) | Overload management in an application-based server | |
| US10397236B1 (en) | Anamoly detection and recovery of a corrupted computing resource | |
| CA2209304A1 (fr) | Procede de surveillance d'une pluralite de types d'objets d'une pluralite de noeuds a partir d'un noeud d'administration dans un systeme informatique | |
| KR102225040B1 (ko) | 인공 지능 기반의 통합 로그 관리 방법 및 그 시스템 | |
| US20200175165A1 (en) | Endpoint detection and response attack process tree auto-play | |
| EP3053320B1 (fr) | Procédé de détection d'anomalies dans un trafic réseau | |
| WO2011117528A1 (fr) | Procede, programme d'ordinateur et dispositif de validation d'execution de taches dans des systemes informatiques evolutifs | |
| US10187264B1 (en) | Gateway path variable detection for metric collection | |
| FR2780589A1 (fr) | Agent de communication entre un administrateur de systeme informatique et un systeme de ressources distribuees et outils de creation d'un tel agent | |
| US20040267750A1 (en) | Automatically facilitated support for complex electronic services | |
| FR2780587A1 (fr) | Agent de communication entre un administrateur de systeme et un systeme de ressources distribuees et procede de traitement d'une requete sur un attribut multi-instanciable | |
| WO2016092218A1 (fr) | Moyens pour déterminer un niveau de pertinence d'une ressource dans un système de traitement d'informations | |
| CN113656378A (zh) | 一种服务器管理方法、装置、介质 | |
| FR2803405A1 (fr) | Procede d'administration d'un systeme informatique ouvert | |
| FR2786581A1 (fr) | Dispositif et procede d'optimisation de surveillance de seuils | |
| EP1065828A1 (fr) | Procédé d'interrogation à distance d'agents SNMP | |
| EP0992910B1 (fr) | Mise à jour d'un journal centralisé d'événements | |
| FR3075996A1 (fr) | Systeme et procede d'elaboration et d'execution de tests fonctionnels pour grappe de serveurs | |
| CN114020558A (zh) | 告警回调方法、平台、系统、装置、设备及存储介质 | |
| CN117472692A (zh) | 基于Java Agent和字节码技术的平台健康监控系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TP | Transmission of property | ||
| PLFP | Fee payment |
Year of fee payment: 18 |
|
| ST | Notification of lapse |
Effective date: 20170228 |