Brevet FR2803407A1 — publié le 20010706

Procédé de création d'un agent par auto-apprentissage et agent ainsi obtenu La présente invention concerne un procédé de création d'un agent par auto-apprentissage et l'agent ainsi obtenu. L'invention est particulièrement impliquée dans les administrateurs de systèmes informatiques et concerne un agent de communication entre un tel administrateur et un système de ressources distribuées. Un tel agent de communication est connu notamment par la demande de brevet intitulée "Agent de communication entre un administrateur de systèmes informatiques et un système de ressources distribuées et outils de création d'un tel agent" déposée par la requérante sous le numéro 98 08297 en date du 30/06/98. Dans cet art antérieur, le système 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...En bref, est considérée comme ressource toute entité du système d'information. Administrer ou gérer un système distribué, c'est manager 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 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 en objets organisés en arbre des informations de management. 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. 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. L'agent, dont il est question, est un agent du protocole de gestion d'un réseau simple (agent SNMP). Le dialogue entre un administrateur et une ressource s'effectue selon le protocole SNMP (Simple Network Management Protocol) le plus répandu dans les plates-formes d'administration de système. Dans une vision très schématique, un agent SNMP peut être découpé en couches standards de communication et en couches amenant des facilités pour encoder et décoder des syntaxes et manipuler des objets. Du fait de la spécificité de chaque ressource, chaque agent doit être créé de façon individuelle pour chacune de ses ressources et doit contenir l'expertise communication avec l'administrateur, appelée également noyau protocolaire, et l'expertise du système à administrer. Les méthodes de développement d'un agent de l'art antérieur consistent pour un programmeur à concevoir dans leur intégralité, l'expertise de communication avec l'administrateur et l'expertise de communication avec la ressource à administrer. Dans son développement, le programmeur est donc confronté à deux types de problèmes, ceux liés au protocole de communication avec l'administrateur et ceux liés au développement de l'expertise de la ressource à administrer. De plus, ces deux expertises ne sont pas dissociées dans l'agent, Dans un tel système selon l'art antérieur, un agent de communication SNMP est figé une fois pour toutes pour un système de ressources distribuées données comportant un certain nombre d'objets. Le problème qui se pose est de savoir comment faire évoluer l'agent pour lui permettre de prendre en compte une modification des ressources distribuées du système représentée par l'introduction, dans un fichier MIB, de nouveaux objets ou de nouvelles classes décrites au format SNMP. Dans l'art antérieur, l'agent était constitué d'un programme exécutable obtenu à partir d'un extrait des fichiers de la MIB puis compilé. Chaque modification des ressources modifiait la MIB et par conséquent nécessitait une modification de l'agent entraînant une recompilation. Un premier but de l'invention est de pallier cet inconvénient en proposant un procédé de création d'un agent qui permette lors du lancement de l'agent de prendre en compte de nouveaux objets. L'invention sera explicitée à l'aide des figures ci-après représentatives d'un exemple non limitatif de réalisation du procédé et de l'agent selon l'invention, dans lesquels : - la figure 1 représente un schéma d'un agent selon l'invention ; - la figure 2 représente le logigramme des étapes du procédé selon l'invention ; - la figure 3 représente la structure des tableaux de bases de données triées ; - la figure 4 représente la structure de la table T1 résultant de l'autoapprentissage de l'agent. L'agent (Ag) selon l'invention, est composé d'un interpréteur (1) et d'un noyau (2). Cet agent communique d'une part avec une plate-forme de management (3) au travers d'un protocole SNMP (30), d'autre part en lecture-écriture avec une MIB (31). Le noyau de l'agent reçoit d'une part les messages SNMP provenant de la plate-forme (3) et d'autre part les messages sous une forme de "socket TCP" venant d'une méthode. Les méthodes contiennent le type d'opération et l'objet sur lequel porte l'opération. Le noyau, lorsqu'il reçoit un message concernant un objet décide après que la phase d'auto-apprentissage se soit déroulée, d'appeler la fonction générique d'un jeu de fonction et ensuite il passe à cette fonction un paramètre défini à l'aide d'une table (T1) et identifiant l'objet. L'agent communique également avec une table de bases de données triées (20) et avec une interface (API) de programme d'application (4). Cette interface de programme d'application permet à un développeur d'agents, la communication avec le noyau par des méthodes. L'agent, selon l'invention, est particularisé en ce qu'il comporte un interpréteur (1) et il n'inclut pas dans son code source les spécificités de la MIB (31) qu'il gère mais va par une phase d'auto-apprentissage de la MIB exécutée lors de son lancement, créer cette table (T1 ) que l'agent utilise par la suite pour déterminer l'identifiant d'un objet. Le noyau de l'agent est développé de façon à reconnaître une structure générique unique de 85 lignes, représentée en annexe 1 et constituée de dix attributs de type entier, cinquante attributs de type chaînes d'octets, cinq attributs de type identifieur d'objet, cinq attributs de type adresse Ip, cinq attributs de type compteur, cinq attributs de type jauge et/ou cinq attributs de type comptage d'intervalle de temps depuis dernier démarrage (Time Ticks). Un fichier d'initialisation ( .confget) permet de préciser pour chaque attribut géré par l'agent le mode d'obtention de sa valeur : ? ? ?, par exemple direct , ce fichier est pris en compte lors de l'initialisation de l'agent. Pour chaque attribut dans le fichier .confget est également précisé l'identifiant de la méthode gérant cet attribut. La structure de donnée choisie est unique, quelle que soit l'instance d'objet qu'elle représente, mais permet malgré tout de décrire la majorité des MIBs SNMP existantes. Comme précisé précédemment, l'interpréteur n'utilise qu'un seul jeu de fonctions pour réaliser les opérations de traitement de requêtes SNMP ou de manipulation des bases de données triées (TBDT) selon l'invention. Ce jeu de fonction comprend les fonctions : "get ; next; testset ; set ; read ; readnext; write. Dans l'art antérieur, l'agent constitué d'un programme compilé utilisait des jeux de fonctions "Mocget ; Moctestset ; Mocset;Mocnext" basées sur chaque classe (Moc) d'objets de la MIB et il existait, pour traiter les requêtes SNMP ou manipuler les bases de données triées, autant de jeux que de classes et des fonctions de manipulation par des requêtes "Read, Readnext, Write" provenant des méthodes. En conséquence, dès que les ressources étaient modifiées et nécessitaient l'introduction d'une nouvelle classe d'objets, le noyau de l'agent devait être modifié pour traiter les nouvelles fonctions associées aux nouvelles classes d'objets et devait nécessiter une réécriture et une nouvelle compilation. Au contraire, l'agent selon l'invention permet de prendre en compte la spécificité de chaque MIB, lors du lancement de l'agent en réalisant les étapes du procédé d'auto-apprentissage qui sera décrit en liaison avec la figure 2. Ce procédé commence par une lecture du fichier MIB stocké selon la syntaxe ASN1-SNMP V1 comme représenté à l'étape (310). Cette étape de lecture est suivie d'une étape (311) d'analyse lexicale de la MIB pour la représenter sous forme d'une structure d'arbre comme représentée à l'étape (312). Le noyau (2) examine ensuite chaque feuille de l'arbre représentant la MIB pour déterminer à l'étape (313) s'il s'agit d'une nouvelle classe (MOC) d'objets gérés (Management Object Class). Dans l'affirmative, le programme crée à l'étape (314) une nouvelle structure (BDT3) dans le tableau de base de données triées (20). Ainsi comme représenté à la figure 3, le tableau comporte une première table dans laquelle les index (IdMOC) de classe d'objets sont incrémentés à chaque fois qu'une base de données triées (BDT,, BDT2, BDT3) est associée à une classe d'objet. La base de données BDT, est associée à l'index 1 et concerne la classe des objets "disque dur d'un système" cette classe ayant, par exemple, deux instances d'objet, un disque dur C et un disque dur D. La base de données BDT2 est associée à l'index 2 et concerne, par exemple, la clase des objets "imprimante". Chaque classe quel que soit l'objet est définie selon la structure générique universelle définie ci-dessus et comportant un maximum de 85 attributs utilisables. Dans l'exemple représenté figure 3, le premier disque C a au premier rang de la structure un premier attribut de type entier qui indique la capacité maximale du disque, à savoir 100 Mégaoctets. Au deuxième rang de la structure, figure le deuxième attribut de type entier qui indique, par exemple le taux de remplissage du disque c'est à dire 30%. Le disque D a quant à lui une capacité maximale de 10 Mégaoctets et un taux de remplissage de 1. Les différents autres attributs jusqu'aux dixième précisent chacun une autre information. Le onzième rang constitue le onzième attribut constitué d'une chaîne d'octets qui fournit le nom (C ou D) affecté au disque dur. Le onzième attribut peut être suivi de quarante neuf autres attributs du même type chaîne d'octets puis des vingt cinq autres attributs constituant la structure. Le cinquantième attribut indique le type de partition (FAT32, ou NTFS) utilisé par le disque. Cette étape (314) permet ainsi l'initialisation de l'index pour chaque type d'objets et l'incrémentation du nombre de classe d'objets (MOC). Cette étape (314) se poursuit par l'étape (315) de test suivante. L'étape (315) est également lancée lorsqu'à l'étape (313) de test de nouvelle MOC, le programme a déterminé qu'il ne s'agissait pas d'une nouvelle MOC. L'étape (315) consiste à tester l'index pour un type d'attribut d'un objet et à déterminer s'il a atteint son maximum. Dans l'affirmative, le programme du noyau produit une sortie avec erreur. Dans la négative, le programme du noyau stocke la feuille de l'arbre de la MIB dans un tableau (T1, figure 4) indiquant dans une première colonne l'indice de feuilles, dans une deuxième colonne le numéro de la MOC sous forme d'indices de classe et dans une troisième colonne le rang de l'attribut dans la structure. En même temps, l'index du type d'attribut correspondant dans la structure est incrémenté. Si celui-ci dépasse la valeur maximum autorisée pour la structure, le programme génère une erreur en sortie comme représenté à l'étape (317). Ainsi à l'issue de l'analyse lexicale (en anglais parsing de la MIB), l'agent peut instancier la structure de données unique décrite en annexe 1. Pour chaque classe d'objets de la MIB, une instance de la structure est créée et l'agent établit une correspondance entre chaque attribut de la structure appartenant à la classe d'objet et un champ de la structure de données grâce au type de l'attribut. En annexe 2 est représenté un exemple d'un fichier de description de MIB comportant un nombre d'objets en dehors des normes définies par la structure. Ce fichier contient onze objets du type entier accessibles uniquement en lecture. Ce fichier MIB comprenant une classe d'objets est composé de onze attributs de type entier alors que la structure utilisée par l'agent est limitée à dix attributs de type entier. Ceci entraîne lors de sa lecture par l'agent l'affichage d'une erreur. L'originalité de l'invention réside également dans l'alliance d'une technologie de construction d'agents SNMP compilés, (l'agent étant constitué, tout comme dans l'art antérieur, d'un programme exécutable) et d'un interpréteur de fichiers d'objets MIB décrits suivant le protocole SNMP (la figure 2 représente dans sa globalité le travail de l'interpréteur). Ainsi l'invention permet un auto-apprentissage de la MIB par un agent en création. Le procédé de création d'un agent par auto-apprentissage de la MIB et sans recompilation consiste avec un agent comportant un noyau compilé, utilisant une structure unique quelle que soit la MIB, associé à un interpréteur à exécuter: - une étape de lecture du fichier de la MIB (310) en langage ASN1 ; - une étape d'analyse lexicale (311) réalisée dynamiquement et de représentation de ce fichier sous forme de structure d'arbres (312) ; - une étape d'analyse de chaque feuille d'arbres et de test de détermination du n#ud précédent pour savoir s'il s'agit d'une classe (MOC) nouvelle (313) ; - dans le cas où il s'agit d'une nouvelle classe (MOC), une étape de création d'une nouvelle structure dans un tableau (20) et - dans le cas contraire une étape d'examen de l'index pour déterminer si le type d'objets de la classe (MOC) a atteint le maximum autorisé par la structure. Selon une autre particularité du procédé dans le cas où l'index du type d'objet n'a pas atteint le maximum autorisé, la feuille de l'arbre est stockée dans la première colonne d'une table (T1) indiquant dans une deuxième colonne le numéro de la classe et dans une troisième colonne le rang de la structure auquel appartient la feuille. Selon une autre particularité du procédé pour chaque objet d'une classe de la MIB, une instance de la structure générique est créée. Selon une autre particularité du procédé le noyau produit un signal de sortie avec erreur dans le cas où l'index d'un type d'objet a atteint le maximum autorisé par la structure. Selon une autre particularité du procédé ou de l'agent, la structure est constituée de: - 10 attributs de type entier ; - 50 attributs de type chaînes d'octets ; - 5 attributs identifiant d'objets ; - 5 attributs d'adresse Ip ; - 5 attributs de type compteur ; - 5 attributs de type jauge ; - 5 attributs time Ticks. Selon une autre particularité du procédé, le noyau de l'agent, selon l'invention, génère après lecture de la MIB et analyse de celle-ci par l'interpréteur auquel le noyau est associé, un tableau (20) de bases de données triées (BDT1, BDT2, BDT3) affectées à chaque classe (MOC) et une table (T1 ) contenant chaque feuille de l'arbre de la MIB. De même l'agent selon l'invention comporte des moyens d'effectuer un auto-apprentissage de la MIB sans recompilation de l'agent comportant un noyau compilé associé à un interpréteur et utilisant une structure unique quelle que soit la MIB, des moyens d'effectuer une lecture systématique du fichier de la MIB (310) en langage ASN1, lors du lancement de l'agent, des moyens de réaliser dynamiquement une analyse lexicale (311) et de représenter ce fichier MIB sous forme de structure d'arbre (312), des moyens d'analyser chaque feuille d'arbre et de déterminer s'il s'agit d'une classe (MOC) nouvelle (313) par un test du n#ud précédent, des moyens de création d'une nouvelle structure dans un tableau (20) et des moyens d'examen de l'index pour déterminer si le type d'objets de la classe (MOC) a atteint le maximum autorisé par la structure. Selon une autre particularité l'agent comporte des moyens de stocker dans la première colonne d'une table (T1) l'indice de la feuille de l'arbre, dans une deuxième colonne le numéro de la classe et dans une troisième colonne le rang de la structure auquel appartient la feuille. Selon une autre particularité l'agent comporte des moyens de créer pour chaque objets d'une classe de la MIB, une instance de la structure générique. Enfin, le noyau de l'agent, génère après lecture de la MIB et analyse de celle-ci par l'interpréteur auquel le noyau est associé, un tableau (20) de bases de données triées (BDT1, BDT2, BDT3) affectées à chaque classe (MOC) et une table (T1 ) contenant chaque feuille de l'arbre de la MIB. D'autres modifications et variantes de réalisation à la portée de l'homme de métier font également partie de l'esprit de l'invention Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes et l'invention ne doit pas être limitée aux détails donnés ci-dessus. Annexe 1 - 10 attributs de type INTEGER ; - 50 attributs de type OCTET STRING ; - 5 attributs de type Objectldentifier ; - 5 attributs de type IpAddress ; - 5 attributs de type Counter ; - 5 attributs de type Gauge ; - et / ou 5 attributs de type TimeTicks. Annexe 2 CONTREFACON-MIB DEFINITIONS ::= BEGIN IMPORTS Gauge FROMRFC1155-SMI transmission, DisplayString FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212; bull OBJECT IDENTIFIER ::={ enterprises 107} gain OBJECT IDENTIFIER ::={ bull 146 } contrefaçon OBJECT IDENTIFIER : :=gain 666} trop-d-entiers OBJECT IDENTIFIER ::={ contrefaçon 1} entierlOBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 1" ::= { trop-d-entiers 1} ntier2 OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 2" ::= { trop-d-entiers 2} entier3 OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 3" ::= { trop-d-entiers 3} entier4 OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 4" ::= { trop-d-entiers 4} entier5 OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 5" ::= { trop-d-entiers 5} entière OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 6" ::= { trop-d-entiers 6} entier7 OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 7" ::= { trop-d-entiers 7} entiers OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 8" ::= { trop-d-entiers 8 } entier9 OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 9" ::= { trop-d-entiers 9} entierlO OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 10" ::= { trop-d-entiers 10} entierllOBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Entier 11 ::= { trop-d-entiers 11} END REVENDICATIONS 1. Procédé de création d'un agent par auto-apprentissage de la base d'informations MIB et sans recompilation, avec un agent comportant un noyau compilé, utilisant une structure unique quelle que soit la MIB et associé à un interpréteur, caractérisé en ce qu'il consiste à exécuter: - une étape de lecture du fichier de la MIB (310) en langage ASN1 ; - une étape d'analyse lexicale (311) réalisée dynamiquement et de représentation de ce fichier sous forme de structure d'arbres (312) ; - une étape d'analyse de chaque feuille d'arbres et de test de détermination du n#ud précédent pour savoir s'il s'agit d'une classe (MOC) nouvelle (313) ; - dans le cas où il s'agit d'une nouvelle classe (MOC), une étape de création d'une nouvelle structure dans un tableau (20) et - dans le cas contraire une étape d'examen de l'index pour déterminer si le type d'objets de la classe (MOC) a atteint le maximum autorisé par la structure. 2. Procédé selon la revendication 1, caractérisé en ce que dans le cas où l'index du type d'objet n'a pas atteint le maximum autorisé, la feuille de l'arbre est stockée dans la première colonne d'une table (T1) indiquant dans une deuxième colonne le numéro de la classe et dans une troisième colonne le rang de la structure auquel appartient la feuille. 3. Procédé selon la revendication 1, caractérisé en ce que pour chaque objets d'une classe de la MIB, une instance de la structure générique est créée. 4. Procédé selon la revendication 1, caractérisé en ce que le noyau produit un signal de sortie avec erreur dans le cas ou l'index d'un type d'objet a atteint le maximum autorisé par la structure. 5. Procédé selon la revendication 1, caractérisé en ce que la structure est constituée de: - 10 attributs de type entier ; - 50 attributs de type chaînes d'octets ; - 5 attributs identifiant d'objets ; - 5 attributs d'adresse Ip ; - 5 attributs de type compteur ; - 5 attributs de type jauge ; - 5 attributs time Ticks. 6. Procédé selon la revendication 1, caractérisé en ce que le noyau de l'agent génère après lecture de la MIB et analyse de celle-ci par l'interpréteur auquel le noyau est associé, un tableau (20) de bases de données triées (BDT1, BDT2, BDT3) affectées à chaque classe (MOC) et une table (T1 ) contenant chaque feuille de l'arbre de la MIB. 7. Agent caractérisé en ce qu'il comporte des moyens d'effectuer un auto-apprentissage de la MIB sans recompilation de l'agent comportant un noyau compilé associé à un interpréteur et utilisant une structure unique quelle que soit la MIB, des moyens d'effectuer une lecture systématique du fichier de la MIB (310) en langage ASN1, lors du lancement de l'agent, des moyens de réaliser dynamiquement une analyse lexicale (311) et de représenter ce fichier MIB sous forme de structure d'arbres (312), des moyens d'analyser chaque feuille d'arbre et de déterminer s'il s'agit d'une classe (MOC) nouvelle (313) par un test du n#ud précédent, des moyens de création d'une nouvelle structure dans un tableau (20) et des moyens d'examen de l'index pour déterminer si le type d'objets de la classe (MOC) a atteint le maximum autorisé par la structure. 8. Agent selon la revendication 7, caractérisé en ce qu'il comporte des moyens de stocker dans la première colonne d'une table (T1) l'indice de la feuille de l'arbre, dans une deuxième colonne le numéro de la classe et dans une troisième colonne le rang de la structure auquel appartient la feuille. 9. Agent selon la revendication 7, caractérisé en ce qu'il comporte des moyens de créer pour chaque objets d'une classe de la MIB, une instance de la structure générique. 10. Agent selon la revendication 7, caractérisé en ce que la structure qu'il utilise est constituée de: - 10 attributs de type entier ; - 50 attributs de type chaînes d'octets ; - 5 attributs identifiant d'objets ; - 5 attributs d'adresse Ip ; - 5 attributs de type compteur ; - 5 attributs de type jauge ; - 5 attributs time Ticks. 11. Agent selon la revendication 7, caractérisé en ce que le noyau comporte des moyens de générer après lecture de la MIB et analyse de celle-ci par l'interpréteur auquel le noyau est associé, un tableau (20) de bases de données triées (BDT1, BDT2, BDT3) affectées à chaque classe (MOC) et une table (T1) contenant chaque feuille de l'arbre de la MIB