FR2803405A1 - Procede d'administration d'un systeme informatique ouvert - Google Patents

Abstract

Procédé de calcul d'indicateur d'un système d'administration de réseau comprenant au moins un sous-administrateur supervisant une partie du réseau, le sous-administrateur comprenant une pluralité de modules permettant la communication avec d'une part les équipements du réseau et d'autre part un administrateur principal, le procédé de calcul étant caractérisé en ce qu'au moins une équation définissant un indicateur et évaluée par un module indicateur du sous-administrateur comprend au moins un attribut d'objet, dont au moins un index est variable, et le procédé comprend- une étape de réception, par le module indicateur, d'une notification transmise par un module de configuration des modèles, cette notification comprenant une adresse d'un équipement et une identification d'une équation représentative d'un indicateur,- une étape d'initialisation, dans laquelle les instances des index variables prennent une valeur d'initialisation ne permettant pas le calcul de l'équation spécifiée.- une étape de détermination de toutes les instances valides de tous les index variables de tous les attributs de l'équation.

Description

<Desc/Clms Page number 1>

Procédé d'administration d'un système informatique ouvert
La présente invention concerne un procédé d'administration d'un système informatique ouvert.

Il est connu par la demande de brevet français FR 98. 04695 déposée le 15. 04.98 intitulée Procédé et système d'administration de réseaux et de systèmes , un procédé d'administration d'un réseau constitué d'une pluralité de sous-réseaux, mettant en #uvre un sous-administrateur appelé COACH localisé sur un réseau local d'entreprise pour administrer un sous réseau et communiquant avec l'administrateur principal. Le sous-administrateur comprend une pluralité de modules permettant d'une part de communiquer et d'administrer les équipements et les applications du sous réseau et d'autre part de communiquer avec l'administrateur principal.

Un des modules du sous administrateur a comme fonction essentielle le calcul d'indicateurs. Un indicateur est une équation dans laquelle des instances d'objets, représentant le fonctionnement des équipements d'un sous réseau, sont introduites. Selon ce document chaque instance d'une équation doit être définie précisément, par un attribut dont le ou les indexs sont parfaitement connus. Ainsi, ce procédé ne permet pas de prendre en compte des équations génériques d'indicateurs, dans lesquelles les instances ne sont pas complètement définies. De plus, ces équations ne permettent pas de prendre en compte automatiquement l'apparition ou la disparition d'équipement et donc d' instances.

La présente invention a donc pour objet de pallier les inconvénients de l'art antérieur en proposant un procédé de calcul d'indicateur permettant d'appliquer une équation sur un ensemble d'objets de manière dynamique.

Ce but est atteint par un procédé de calcul d'indicateur d'un système d'administration de réseau comprenant au moins un sous-administrateur supervisant une partie du réseau, le sous-administrateur comprenant une pluralité de modules permettant la communication avec d'une part les équipements du réseau et d'autre part un administrateur principal, le procédé de calcul étant caractérisé en ce qu'au moins une équation définissant un

<Desc/Clms Page number 2>

indicateur et évaluée par un module indicateur du sous-administrateur comprend au moins un attribut d'objet, dont au moins un index est variable, et le procédé comprend - une étape de réception, par le module indicateur, d'une notification transmise par un module de configuration des modèles, cette notification comprenant une adresse d'un équipement et une identification d'une équation représentative d'un indicateur, - une étape d'initialisation, dans laquelle les instances des index variables prennent une valeur d'initialisation ne permettant pas le calcul de l'équation spécifiée, - une étape de détermination de toutes les instances valides de tous les index variables de tous les attributs de l'équation.

Des développements supplémentaires de l'invention sont décrits dans les revendications dépendantes.

L'invention, avec ses caractéristiques et avantages, ressortira plus clairement à la lecture de la description faites en référence aux dessins annexés dans lesquels : - la figure 1 représente un logigramme du procédé d'implémentation d'une équation d'indicateur à index variable, - la figure 2 représente un logigramme du procédé de mise à jour des instances des index variables, - les figures 3A et 3B représentent un exemple d'architecture d'un sous administrateur utilisé dans le procédé selon l'invention.

Le sous-administrateur (COACH) décrit dans la demande de brevet français FR 98. 04695 déposée le 15. 04.98 est représenté en figure 3A et 3B.

Ce sous-administrateur comporte un ensemble de processus aussi appelés "modules" (MCG, MFA, MD, MCM, MCI) qui dialoguent les uns avec les autres et avec l'administrateur principal (AD) par l'intermédiaire d'un processus central aussi appelé "noyau" (N). Les dialogues entre les différents modules se font par un support (socket) portable et standard. Chaque module (MCG, MFA, MD, MCM, MCI) est dédié à une fonction précise. Nous reprendrons dans la suite de

<Desc/Clms Page number 3>

la description uniquement les éléments de description des principaux modules mis en #uvre dans la présente invention.

Le module central ou noyau (N) a deux fonctions principales. D'une part, il dialogue avec l'administrateur (AD1) et d'autre part, il gère le dialogue entre les différents modules composant le sous-administrateur (COACH). En effet, le noyau (N) répond par un dialogue selon le protocole SNMP, lorsque le sous-administrateur (COACH) est interrogé ou configuré par l'administrateur. Il existe deux types de dialogue avec les modules, c'est pourquoi deux supports (sockets) de communication sont souhaitables pour gérer le dialogue noyaumodule. Le premier type de dialogue se fait à l'initiative du noyau et concerne les mises à jour d'instances ou les demandes d'informations sur une base de gestion d'informations (MIB) ou les transmissions de notifications provenant d'un autre module. Le second type de dialogue se fait à l'initiative des modules et concerne les demandes d'informations ou les mises à jour d'instances de la base de gestion d'informations (MIB). Le noyau gère deux listes de supports. La création de support dans chacune de ces listes se fait dynamiquement lors de la connexion des modules. Pour le dialogue (SNMP) avec l'administrateur, le standard impose l'utilisation d'un seul support (socket). Le dialogue se fait sur le port 161/udp, mais l'utilisation d'un répartiteur (dispatcher) de requêtes nécessite l'utilisation d'un autre port paramétrable afin d'avoir la possibilité de faire fonctionner plusieurs agents (SNMP) sur un même équipement. Pour simplifier la gestion de communication avec les modules, une interface commune est définie sous forme de librairie. Par ailleurs, le noyau (N) possède une mémoire cache (cache memory) contenant toutes les informations résultant de l'administration d'un sous-réseau (RLE). Chaque module (MCG, MFA, MD, MCM, MCI) interroge le noyau (N) pour initialiser ces paramètres de fonctionnement. En outre, le noyau (N) gère une base de données contenant toutes les instances de la base de gestion d'informations (MIB) du sous-réseau administré par le sous-administrateur (COACH).

Le module de découverte (MD) découvre le sous réseau (RLE1) sur lequel est installé le sous-administrateur (COACH 11). A l'aide d'une table des masques d'adresse du protocole internet (IP, Internet Protocol), le module de

<Desc/Clms Page number 4>

découverte (MD) détermine les adresses (IP) des équipements (ET) que le sous-administrateur peut éventuellement administrer. Puis, le module de découverte (MD) interroge successivement, par groupe de paquet internet (PING Packet Internet Grooper) unitaire, tous les équipements possibles. Le PING est une interrogation standard que l'on peut utiliser pour savoir si une machine est connectée sur le réseau Internet, pour déterminer la provenance d'un message ou pour vérifier si un système est toujours en activité. Lorsqu'un équipement est visible sur le réseau, il répond au PING.

Si un équipement est découvert, le module de découverte (MD) recherche son domaine. Chaque équipement appartient à au moins un domaine. Le domaine de chaque équipement permet de définir des groupes d'indicateurs et de filtres d'alarme à injecter sur chacun des équipements et ceci, en fonction des agents présents sur ces équipements et donc en fonction des rôles dépourvus à chaque équipement.

Le domaine d'un équipement est défini selon la réponse ou non de l'équipement à un ensemble d'instances d'objets de la base de gestion d'informations (MIB snmp). Dès la découverte d'un nouvel équipement, une interrogation par scrutation (polling) est effectuée sur un ensemble d'instances d'objets (SNMP). Lorsqu'un équipement (ET) découvert répond aux interrogations de toutes les instances d'objets définissant un domaine, on dit que l'équipement appartient à ce domaine. Tous les équipements découverts sont classés selon des domaines. Ces domaines permettent de différencier les différents types d'équipements et d'administrer différemment chacun des équipements selon son domaine. Un équipement peut appartenir à plusieurs domaines.

Le domaine MIB2 pourrait, par exemple, être défini par la réponse à l'instance "sysUpTimeO". Tous les équipements découverts sont interrogés sur cette instance. Ceux qui y répondent appartiennent au moins au domaine MIB2.

Enfin, lorsque le module de découverte (MD) a découvert un équipement et son domaine, il envoie une notification à un module de configuration des modèles (MCM) en lui indiquant l'adresse du protocole internet (IP) de l'équipement découvert et le domaine auquel cet équipement

<Desc/Clms Page number 5>

appartient. Avantageusement, le module de découverte (MD) envoie, de plus, ces mêmes informations au noyau (N) qui les stockera dans une base de données.

Généralement, lorsqu'un système existant est découvert une seconde fois, son domaine n'est pas, à nouveau, recherché. Néanmoins, le domaine d'un système peut être recherché en positionnant sur "actif' (ON) l'instance de la base de gestion d'informations (MIB) relative à la découverte des domaines.

Dans ce cas si, le domaine n'est pas le même que le précédent, la base de données du noyau est automatiquement mise à jour et des notifications sont automatiquement envoyées au module de configuration des modèles (MCM).

Le module de calcul d'indicateur (MCI) calcule des indicateurs sur les équipements (ET) à administrer. Un indicateur est une équation dans laquelle des instances d'objets de gestion de base d'informations (MIB snmp) sont introduites. Les valeurs de ces instances d'objets sont obtenues par l'interrogation (polling) sur les agents (snmp) fonctionnant sur chacun des systèmes à administrer. Le résultat de cette équation est comparé à une valeur seuil ne devant pas être dépassée un certain nombre de fois pendant un certain laps de temps. Lorsque la valeur seuil est dépassée, un certain nombre de fois pendant un certain laps de temps, une alarme est émise vers l'administrateur principal (AD1).

Prenons l'exemple d'un indicateur à instancier sur les équipements du domaine MIB2 comportant une période d'interrogation de 60 secondes. Selon l'art antérieur, cet indicateur calcule l'utilisation de la bande passante d'une carte de réseau dont l'index est 1 à l'aide de l'équation: (8*$- (iflnOctets.1 + ifOutOctets.1) /ifSpeed.1
Cette équation sera calculée sur chacun des équipements du domaine MIB2 toutes les minutes. Si, sur un système "A", le résultat excède la valeur 10 au moins deux fois en cinq minutes, une alarme sera envoyée à l'administrateur principal (AD1). Et cette alarme sera perçue par ce dernier comme provenant du système "A".

Un indicateur comporte des opérateurs simples tels que l'addition (+), la soustraction (-), la multiplication (*), la division (/) et des opérateurs d'ensemble.

<Desc/Clms Page number 6>

Les opérateurs d'ensemble permettent d'appliquer un opérateur sur des séries d'instances d'indicateurs. Ainsi, l'opérateur : - ! SUM qui réalise la somme d'une série d'instances d'indicateurs , - !MOY qui réalise une moyenne d'une série d'indicateurs, - !MAX qui recherche la valeur maximum parmi une série d'indicateurs, - !MIN qui recherche la valeur minimum parmi une série d'indicateurs.

Attention, les opérateurs d'ensemble sont appliqués à des systèmes et non au temps. De plus, un indicateur peut également comprendre un opérateur delta noté $- et un opérateur d'indirection temporel noté &. L'opérateur delta est défini tel que, à l'instant t, $- (x) x(t) - x(t-T) où l'attribut x de valeur x(t- T) est recueilli à l'instant (t - T) et où la valeur $- (x) donne la différence entre x (t) x(t- T). $- (x) correspond à un delta et $t à un delta(t). L'opérateur d'indirection temporel permet de réutiliser un calcul déjà effectué sur un équipement. Le module de calcul des instances (MCI) interroge le noyau pour initialiser ces paramètres de fonctionnement. L'annexe 1 donne un exemple de fichier de configuration contenant un indicateur.

Ainsi, le module de découverte permet de définir pour chaque adresse IP le type d'équipement éventuellement connecté à cette adresse et à quel domaine appartient cet équipement.

En fonction du domaine d'un équipement un module dit de configuration des modèles détermine, par exemple, en consultant une table, quelle est l'équation que le module d'indicateur doit utiliser sur une adresse particulière.

La table comprend en fait les associations domaine/identification de l'équation.

Lorsque le protocole d'administration est le protocole SNMP, la collecte des informations, c'est-à-dire des instances d'objets, permettant l'évaluation d'un indicateur, est effectuée par des agents SNMP. Une instance d'un attribut d'un objet est identifiée par son nom en toutes lettres et un ou plusieurs index.

Lorsqu'il existe plusieurs instances pour un même attribut, celles-ci sont différenciées par l'intermédiaire d'un index de valeur différente. Les index peuvent être soit des entiers, soit des chaînes de caractères, soit des adresses IP, soit des identificateurs d'objet.

<Desc/Clms Page number 7>

A titre d'exemple, si un équipement possède deux adresses IP, cette information sera renseignée par un agent SNMP, dans une table sous la forme :
Instance : IpAddress.1
Type : IpAddress
Value: 129. 182.165.2 et
Instance : IpAddress.2
Type : IpAddress
Value: 129. 182.165.3
De même, un attribut peut avoir plusieurs index de types différents. Une autre particularité du protocole d'administration SNMP est que les agents fixent la valeur des index selon leur propre logique.

Le but de l'invention est de pouvoir écrire et d'évaluer une équation dans laquelle les index des attributs, introduits dans l'équation, sont variables et indéfinis au début de l'évaluation de l'équation. Ainsi, l'équation précédente pourra s'écrire: (8*$- (iflnOctets. ?11 + ifOutOctets. ?I1) /ifSpeed. ?11
Où, par exemple, l'index de l'attribut IflnOctets est remplacé par ?11 qui est alors une variable qui peut prendre a priori n'importe quelles valeurs entières.

Cette formulation permet ainsi d'interroger sur une même adresse IP, avec une seule équation, c'est-à-dire un seul indicateur, tous les équipements ou applications d'un même type sans connaître a priori le nombre et la valeur des index des attributs des équipements ou applications à interroger. Cette formulation permet également d'introduire des contraintes sur les valeurs possibles des index. Ainsi, il est possible de n'interroger qu'une partie seulement des équipements dont le ou les index des attributs vérifient la ou les contraintes spécifiées.

Pour autoriser une telle équation, le module indicateur du sous administrateur selon l'invention gère une structure particulière, par exemple un ensemble de tables. Cet ensemble de tables comprend d'une part pour chaque

<Desc/Clms Page number 8>

adresse IP, l'identification de l'équation et l'ensemble des valeurs des index possibles pour l'évaluation de l'équation et d'autre part une table mémorisant les correspondances entre les identifiants des équations et les équations.

A titre d'exemple ces tables se présentent de la façon suivante :
Table N 1

<tb>
<tb> Adresse <SEP> IP <SEP> Index <SEP> du <SEP> Modèle <SEP> Valeur <SEP> du <SEP> (des) <SEP> Instance(s)
<tb> 129. <SEP> 182.165.200 <SEP> 1 <SEP> 11=1
<tb> 129. <SEP> 182.165.200 <SEP> 1 <SEP> Il <SEP> =3 <SEP>
<tb> 129. <SEP> 182.165.200 <SEP> 1 <SEP> Il <SEP> =7 <SEP>
<tb> Table <SEP> N 2
<tb> Index <SEP> du <SEP> modèle <SEP> Equation
<tb> 1 <SEP> DELTA(ifInErrors. <SEP> ?Il+ifOutErrors. <SEP> ?I1)/DELTA(ifInPackets. <SEP> ?Il
<tb> +ifOutPackets. <SEP> ?Il)
<tb> 2 <SEP> ...
<tb>

Dans cet exemple, l'équation d'index 1 permet de calculer le taux d'erreur d'une carte d'interface réseau. Lorsque cette équation est appliquée, par exemple, à l'adresse IP 129. 182.165.200, celle-ci correspond, par exemple, à un routeur. Pour ce routeur particulier, l'index 11 prend trois valeurs (1,3, 7) différentes à un instant t donné. Cela signifie qu'à cet instant, le routeur possède trois interfaces et que l'équation d'index 1 sera évaluée pour chacune de ces interfaces.

Dans cet exemple le choix de l'équation est effectué préalablement par le module de découverte qui a déterminé qu'un routeur était connecté à l'adresse IP 129. 182.165.200. cette information est ensuite transmise par le module (MCM) de configuration des modèles, au module (MCI) indicateur.

Lorsque le nombre d'interfaces varie au cours du temps sur ce même routeur, l'application de l'équation par le module d'indicateur, déclenchera une procédure spécifique permettant de déterminer quelles sont les valeurs de l'index 11 et donc d'évaluer l'équation de l'indicateur avec éventuellement des valeurs d'index différentes.

On comprend, par conséquent, que l'utilisation d'une équation du type défini précédemment, permet de prendre en compte dynamiquement une

<Desc/Clms Page number 9>

population d'objets du même type et ceci même lorsque des objets de cette population apparaissent ou disparaissent au cours du temps.

Cet ensemble de tables est également utilisé par le module d'indicateur pour d'une part mettre en place un modèle d'équation sur une adresse IP déterminée, et d'autre part pour mettre à jour les indicateurs.

Selon l'invention, les index des attributs d'un indicateur peuvent être de deux types entier ou chaîne. Un index de type entier, est noté ?In, où n permet d'identifier un index lorsqu'un attribut comprend plusieurs index. Un index de type chaîne de caractères est noté ?Sn.

La mise en place d'index d'attributs variables dans une équation représentative d'un indicateur implique le respect de certaines contraintes sur les index et notamment sur le nombre des index. En effet, plus un attribut déterminé d'une équation comprend d'index, plus la mémoire nécessaire pour le calcul de cet attribut est importante. L'expérience a démontré que pour obtenir une taille de processus compatible avec une utilisation industrielle du procédé selon l'invention il est souhaitable de limiter à 5 le nombre d'index par attribut, quel que soit le type de l'index.

De même, au moins un attribut dit fédérateur de l'équation représentative de chaque indicateur doit comprendre tous les index variables de l'équation. Cette contrainte est fixée pour deux raisons. Premièrement, l'attribut fédérateur est utilisé lors de l'évaluation de l'équation (décrite ultérieurement) pour retrouver toutes les instances possibles de l'ensemble des attributs de l'équation. Deuxièmement, si un tel attribut n'existe pas dans l'équation alors cela signifie qu'au moins deux attributs de l'équation sont décorrélés. Par conséquent, l'équation n'a plus de sens.

La mise en place d'attributs à index variables dans une équation d'indicateur permet également d'évaluer cette équation uniquement pour des valeurs déterminées d'index. En effet, en fixant des contraintes sur les valeurs que peuvent prendre les index il est possible de choisir des attributs particulier pour lesquels l'équation sera évaluée. A titre d'exemple prenons l'indicateur permettant de connaître le taux de fragmentation d'une base de données. Selon l'invention cette équation s'écrit :

<Desc/Clms Page number 10>

(TauxFragmentation ?11. ?12)*1024
Où 11 représente l'identification d'une base de données et 12 représente un tableau de cette base de données. Si l'utilisateur souhaite connaître tous les taux de fragmentation de tous les tableaux de toutes les bases de données, aucune contrainte n'est nécessaire sur les index 11 et 12. Par contre, si l'utilisateur souhaite connaître le taux de fragmentation de tous les tableaux d'une base de données particulière, alors il est nécessaire d'ajouter une contrainte sur l'index 11. cette contrainte est par exemple de la forme : Dbname. ?11= nom base de données
Ce qui signifie que la valeur de 11 est choisi pour que le nom de la base de données soit nom de la base de données .

Les étapes du procédé selon l'invention vont à présent être explicitées en référence aux figures 1 et 2. Comme expliqué précédemment, le module de découverte du sous-administrateur réalise la découverte des équipements à superviser. Ensuite un module de configuration transmet au module indicateur tous les renseignements (adresse IP, type d'équation) de façon à ce que celuici renseigne la table 1. Ainsi, pour chaque équipement supervisé le module indicateur du sous-administrateur connaît le type d'équation à appliquer.

Lorsque le module indicateur reçoit une information du module de configuration l'informant qu'un nouvel équipement est à superviser, le module indicateur déclenche une étape d'initialisation (10). Cette étape d'initialisation (10) consiste à renseigner la table N 1 en ajoutant, pour chaque index de l'équation, une ligne contenant l'adresse du nouvel équipement, l'index du modèle de l'équation et une valeur d'initialisation pour l'index. cette valeur d'initialisation est, par exemple, -1 lorsque l'index est de type entier, ou par exemple une chaîne de caractères vide lorsque l'index est de type chaîne de caractères.

Ensuite le module indicateur déclenche une étape d'évaluation de l'indicateur sur l'adresse spécifiée. Cette étape d'évaluation consiste, d'une part à rechercher toutes les instances possibles et valides de tous les index de tous les attributs de l'équation, et d'autre part à réaliser l'évaluation de l'équation pour toutes les instances valides des index.

<Desc/Clms Page number 11>

La recherche des instances des index des attributs de l'équation consiste tout d'abord en une étape (11) de recherche de l'attribut fédérateur de l'équation. Pour ce faire, le module (MCI, figure 3) indicateur comprend une procédure d'analyse de l'équation qui compte le nombre d'index pour chaque attribut et qui choisit l'attribut ayant le plus d'index comme attribut fédérateur. Lorsque plusieurs attributs ont le même nombre d'index, le premier attribut peut alors être arbitrairement choisi comme attribut fédérateur. De même, une autre solution consiste à écrire les équations en choisissant le premier attribut rencontré dans l'équation comme attribut fédérateur. Dans ce mode de réalisation, l'étape de recherche (11) de l'attribut fédérateur consiste simplement à extraire le ou les index du premier attribut de l'équation.

De même, lorsque des contraintes sur les index sont introduites. Le choix de l'attribut fédérateur se portera sur l'attribut qui, en plus d'avoir le plus grand nombre d'index, a les contraintes sur ses index.

En effet afin de simplifier le processus de traitement des équations l'ensemble des contraintes existantes sur les index de l'équations est reporté sur l'attribut fédérateur qui, par définition, comprend tous les index.

Ensuite, le module indicateur déclenche une étape d'extraction des attributs de l'équation. Cette étape consiste en fait à déterminer les valeurs des index des attributs pour lesquelles l'équation est calculable. Pour ce faire le module indicateur déclenche l'envoi, à l'étape (12) de requêtes d'interrogation Getnext sur l'adresse spécifiée en demandant la valeur suivante de l'attribut fédérateur. Lorsque le protocole d'administration choisi est le protocole SNMP, cette interrogation est réalisée par l'intermédiaire d'agents SNMP.

A ce stade deux cas de figure sont possibles. Premièrement, l'agent retourne une valeur ne correspondant pas à l'attribut fédérateur ou une erreur, ce qui signifie que l'attribut n'existe pas. Dans ce cas, le procédé de calcul d'indicateur s'arrête, mais la valeur d'initialisation de tous les index est conservée, de façon à pouvoir effectuer une mise à jour ultérieurement.

Deuxièmement l'agent retourne une instance pour l'attribut fédérateur, alors le module d'indicateur extrait à l'étape (13) l'instance de tous les index de l'attribut fédérateur pour former alors un ensemble ordonné de valeur

<Desc/Clms Page number 12>

communément appelé n-uplet de valeurs. Ensuite, le module indicateur vérifie à l'étape (14) si la ou les instances des index du n-uplet trouvé répondent aux éventuelles contraintes fixées pour les index. Si l'une des contraintes n'est pas respectée sur l'un des index, alors les instances des index sont ignorées et la valeur suivante de l'attribut fédérateur est demandée.

Si au contraire, toutes les contraintes sont satisfaites, alors le module indicateur envoie à l'étape (15) pour chaque autre attribut de l'équation une requête d'interrogation avec pour valeurs d'index celles du n-uplet précédemment trouvé.

Si l'agent SNMP retourne un résultat sans erreur pour toutes les instances d'attributs demandées, alors le module indicateur, soit remplace à l'étape (16) le n-uplet d'instance d'index dans la table N 1, si cette instance correspond à la première trouvée, soit ajoute à l'étape (16) une ligne dans la table N 1 en conservant la même adresse et le même index de modèle, et en renseignant la colonne valeur des instances avec la nouvelle valeur trouvée pour le n-uplet d'index. Ensuite, le module indicateur demande la valeur suivante de l'attribut fédérateur.

Si l'une des instances d'attributs demandées n'existe pas le module indicateur demande la valeur suivante de l'attribut fédérateur sans mémoriser la valeur du n-uplet d'index correspondant.

Ensuite, l'ensemble de la procédure se répète jusqu'à ce que l'agent réponde à la requête Getnext de demande de la valeur suivante de l'attribut fédérateur par une instance d'un autre attribut ou par une erreur. Cela signifie alors que toutes les instances de l'attribut fédérateur ont été trouvées et que la recherche des instances des index est terminée.

Ainsi, lors de l'évaluation ultérieure de l'équation le module indicateur récupère les instances des index mémorisées dans la table N 1, puis interroge les agents SNMP avec comme paramètre les attributs indexés avec les instances trouvées dans la table N 1. Si aucune instance d'index valide n'est mémorisée dans la table N 1, alors la dernière ligne de la table contenant une valeur d'une instance d'index est marquée d'un drapeau (en anglais : Flag)

<Desc/Clms Page number 13>

indiquant au module indicateur que cette instance d'index n'est pas valide, de sorte que le calcul de l'équation correspondante n'est pas réalisé.

A titre d'exemple, si l'équation à évaluer est l'équation d'index 1 de la table N 2, le module indicateur demande dans un premier temps la valeur suivante de l'attribut IflnErrors. Si l'agent retourne une valeur pour IflnErrors. 1 alors, le module indicateur interroge l'agent SNMP pour connaître les instances des attributs ifOutErrors.l, iflnPacketsl et ifOutPackets.l. Si toutes ces instances existent, l'instance 11=1 est mémorisée dans la table N 1, puis la valeur suivante de l'attribut IfInErrors est demandée. Si l'une de ces instances n'existe pas, la valeur suivante de l'attribut IflnErrors est demandée.

La procédure se répète alors jusqu'à ce que l'agent réponde à la requête de demande de l'instance IfInErrors par une valeur erronée, par exemple, correspondant à un autre attribut. Dans notre exemple, le module indicateur a trouvé en tous trois instances pour l'index 11 qui sont 1, 3 et 7.

Pour suivre l'évolution du domaine supervisé, par le sous administrateur selon l'invention, une étape de mise à jour des instances est réalisée, par exemple, périodiquement. Ainsi, selon l'invention, l'évolution du sous domaine, et en particulier l'évolution des équipements eux-mêmes est prise en compte dynamiquement par le module indicateur.

Cette étape de mise à jour consiste, d'une part à vérifier que les instances des n-uplets d'index valides et mémorisées dans la table N 1 sont toujours valides, et d'autre part à vérifier s'il n'existe pas d'autre instance d'index. L'étape de vérification de l'existence de nouvelles instances d'index est réalisée par le module indicateur qui envoie à l'étape (200, fig. 2) une requête d'interrogation pour demander la première instance de l'attribut fédérateur de l'équation. Dès que l'agent SNMP interrogé retourne une instance de l'attribut fédérateur, le module indicateur extrait la valeur des index trouvés et les compare à l'étape (201) avec les instances des n-uplets d'index mémorisés dans la table N 1. Si les instances trouvées correspondent à un n-uplet déjà mémorisé, le module indicateur envoie à l'étape (202) pour chaque autre attribut de l'équation une requête d'interrogation avec pour valeurs d'index celles du n-uplet trouvé. Si l'agent SNMP retourne un résultat sans erreur pour

<Desc/Clms Page number 14>

toutes les instances d'attributs demandées, le module indicateur vérifie à l'étape (203), s'il y en a, si les contraintes sur les index sont respectées. Si les contraintes sont respectées le module indicateur marque à l'étape (207) la ligne par un drapeau (en anglais : Flag) indiquant que cette instance d'index a été trouvée. Après cette opération à l'étape (207) de marquage, si, lors de l'envoi à l'étape (202) de la requête d'interrogation ayant pour valeurs d'index celles du n-uplet précédemment trouvé, l'une des instance n'est pas retournée, l'instance suivante de l'attribut fédérateur est demandée à l'étape (200). Si les contraintes sur les index ne sont pas respectées l'étape 207 est ignorée et l'instance suivante de l'attribut fédérateur est demandée.

Si lors de la comparaison le module indicateur ne retrouve pas, dans la table N 1, le n-uplet d'index retourné par l'agent SNMP, le module indicateur vérifie à l'étape (203), s'il y en a, si les contraintes sur les index sont respectées. Si ces contraintes sont respectées, le module indicateur envoie à l'étape (204) pour chaque autre attribut de l'équation une requête d'interrogation avec pour valeurs d'index celles du n-uplet précédemment trouvé. Si l'une des contraintes n'est pas satisfaite, la valeur du n-uplet est ignorée et la valeur suivante de l'attribut fédérateur est demandée à l'étape (200).

Si l'agent SNMP retourne un résultat sans erreur pour toutes les instances d'attributs demandées, le module indicateur ajoute alors, à l'étape (205), une ligne à la table N 1 dans laquelle la nouvelle instance du n-uplet d'index est mémorisée. Puis le module indicateur marque à l'étape (206) cette nouvelle ligne avec un drapeau avant de demander à l'étape (200) l'instance suivante de l'attribut fédérateur. Si lors de l'envoi à l'étape (204) de la requête d'interrogation avec pour valeurs d'index celles du n-uplet précédemment trouvé l'une des instances n'est pas retournée le n-uplet d'index est ignoré
L'ensemble de la procédure décrite précédemment se répète jusqu'à ce que l'agent réponde à la requête Getnext de demande de la valeur suivante de l'attribut fédérateur par une instance d'un autre attribut ou par une erreur.

Cela signifie alors que toutes les instances de l'attribut fédérateur ont été trouvées.

<Desc/Clms Page number 15>

Le module indicateur vérifie ensuite la validité des n-uplet d'instances d'index de la table N 1. Pour ce faire, le module indicateur compte à l'étape (210), dans un premier temps le nombre de n-uplet trouvés dans la table N 1 pour une adresse IP et une équation déterminées, initialise à l'étape (210) un premier compteur avec le nombre de lignes trouvées et initialise à l'étape (210) un deuxième compteur à zéro. Ensuite, dans une étape de vérification à l'étape (211), le module indicateur vérifie, pour chaque ligne comprenant l'adresse IP et l'équation déterminée, si un drapeau est présent. Si pour la ligne courante un drapeau est présent, le premier compteur est décrémenté (212) de 1. Une étape de test (213) permet de vérifier la valeur du premier compteur. Si ce premier compteur est égal à zéro alors la procédure se termine, sinon la ligne suivante est traitée.

Si pour une ligne il n'y a pas de drapeau, le deuxième compteur est incrémenté à l'étape (214) de 1 puis comparé à l'étape (214) avec le nombre de ligne précédemment déterminé. S'il y a égalité, la ligne n'est pas supprimée puisqu'il s'agit en fait de la dernière ligne pour cette adresse et cette équation.

Cependant afin d'invalider les informations contenues dans cette ligne pour qu'elle ne soit pas prise en compte lors d'une évaluation ultérieure de l'équation, le module indicateur place à l'étape (215) un drapeau indiquant que le n-uplet d'instances d'attribut n'est pas valide. De plus, puisqu'il s'agit de la dernière ligne l'étape de vérification se termine.

Si la valeur du deuxième compteur est différente du nombre de ligne, la ligne courante est supprimée à l'étape (216). Ensuite le premier compteur est décrémenté à l'étape (217) de 1. Une étape de test à l'étape (218) permet de vérifier la valeur du premier compteur. Si le premier compteur est égal à zéro l'étape de vérification est terminée, sinon la ligne suivante est traitée de la même façon.

Le choix de conserver une ligne, même non valide dans la table N 1, permet d'effectuer ultérieurement une nouvelle mise à jour sur cette adresse IP et cette équation pour suivre ainsi, l'apparition ou la disparition d'équipements ou d'applications sur cette adresse IP.

<Desc/Clms Page number 16>

Comme expliqué précédemment une mise à jour est effectuée périodiquement pour prendre en compte dynamiquement l'évolution du domaine à superviser. Dans une variante de réalisation la période appliquée pour les mises à jour est plus longue. Ainsi, plusieurs évaluations d'une équation peuvent intervenir entre deux mises à jour. De plus, la période de mise à jour peut être décalée par rapport à la période d'évaluation de l'équation correspondante de sorte qu'une mise à jours n'intervienne pas en même temps qu'une évaluation afin de ne pas surcharger le réseau, de ne pas utiliser d'instance d'index non valide et de ne pas provoquer d'accès simultané en lecture et en écriture dans la table N 1.

Ainsi, le procédé de calcul d'indicateur d'un système d'administration de réseau selon l'invention se caractérisé par le fait qu'au moins une équation définissant un indicateur et évaluée par un module indicateur du sousadministrateur comprend au moins un attribut d'objet, dont au moins un index est variable, et que le procédé comprend - une étape de réception, par le module indicateur, d'une notification transmise par un module de configuration des modèles, cette notification comprenant une adresse d'un équipement et une identification d'une équation représentative d'un indicateur, - une étape d'initialisation, dans laquelle les instances des index variables prennent une valeur d'initialisation ne permettant pas le calcul de l'équation spécifiée, - une étape de détermination de toutes les instances valides de tous les index variables de tous les attributs de l'équation.

Dans un autre mode de réalisation le procédé comprend : - une étape de recherche, dans l'équation, d'un attribut appelé attribut fédérateur comprenant le plus grand nombre d'index variable, - une étape d'envoi d'une requête d'interrogation demandant successivement l'instance suivante de l'attribut fédérateur, - une étape d'extraction des instances de chaque index variable de l'attribut fédérateur,

<Desc/Clms Page number 17>

- une étape d'envoi d'une requête d'interrogation demandant les instances des attributs de l'équation ayant comme valeur d'index variable, les valeurs extraites dans l'étape précédente, - une étape de mémorisation des instances d'index variables pour lesquelles une instance a été trouvée pour tous les attributs de l'équation
Dans un autre mode de réalisation, la définition des index dans l'équation, comprend des contraintes limitant le nombre d'instances possibles pour au moins un index variable.

Dans un autre mode de réalisation, le procédé comprend une étape de vérification, permettant de contrôler si les instances des index extraites de l'attribut fédérateur respectent les contraintes spécifiées.

Dans un autre mode de réalisation, le procédé comprend une étape de mise à jour des instances des index réalisée périodiquement.

Dans un autre mode de réalisation, l'étape de mise à jour comprend : - une étape d'envoi d'une requête d'interrogation demandant successivement toutes les instances de l'attribut fédérateur, - une étape de comparaison des instances d'index trouvées avec les instances précédentes des index, - une étape de vérification de la validité d'une part des instances d'index trouvées qui correspondent à des instances précédentes d'index, et d'autre part des instances d'index trouvées qui ne correspondent pas à des instances précédentes d'index, - une étape de suppression des instances précédentes d'index qui n'ont pas été trouvées ou qui ne sont plus valides.

- une étape d'ajout des instances d'index trouvées et validées.

Dans un autre mode de réalisation, l'étape de validation des instances comprend une étape d'envoi d'une requête d'interrogation demandant les instances des attributs de l'équation ayant comme valeurs d'index variable, les instances trouvées dans l'étape précédente.

Dans un autre mode de réalisation, l'étape de suppression des instances précédentes d'index qui n'ont pas été trouvées ou qui ne sont plus valides comprend :

<Desc/Clms Page number 18>

- une étape de marquage des instances d'index validée lors de l'étape de vérification de validité, - une étape de comptage du nombre total d'instance d'index, - une étape de suppression de toutes les instances d'index non marquées, sauf une.

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.

<Desc/Clms Page number 19>

ANNEXE 1 # SECTION de description des indicateurs # # type : IND FIL respectivement INDicateurs ou FILtre # Id : index d'indicateur (génération automatique) # Nom : nom de l'indicateur # Domaine : regroupement de systèmes managés trouvés par leur adresse en domaines identifiables par 5 requêtes get envoyées par COACH # Equation : équation de l'indicateur # T polling : période de polling ou de construction de l'indicateur # Seuil : seuil de décision pour l'émission d'un trap # Apparition : nombre d'apparitions de la valeur de seuil après laquelle, il y a émission de traps # Période : sur quelle période apparaissent les x valeurs de seuil # Sens de comparaison : sens de comparaison entre le seuil et le résultat # Log : indique si l'indicateur devra être loggué ou non # # Format de la ligne de description # type ! 1 Id 1 Nom1 Domaine1 EquationT pollingseuil x foisen T secondes sens du test 1 log # # AXA/COACH/internet/indicators # Les exemples d'indicateur présentés ci-dessous sont donné dans la forme de l'art antérieur. Selon l'invention l'un quelconque des index d'attribut pourrai être remplacé par un index variable noté ? In ou ?Sn.

# % d'utilisation de la bande passante sur l'interface

<Desc/Clms Page number 20>

IND 1 ifUtilizationBandWith 2(((8*$(ifInOctets.l+ifOutOctets.l))/$t)/ifSpeed.l)*100 600 10 1 1200 > LOG # % d'utilisation de la bande passante sur le segment IND 2 ifUtilizationBandWithAll 3 SUM(ifUtilizationBandWith) 1210 10 1 3 3600 > LOG # Debit de réjection de paquets en entrée et sortie sur le segment IND 3 ifDiscards 2 @-(ifInDiscards.1+ifOutDiscards.1) 120 1 1 120 > LOG # Somme des débits de réjection de paquets en entrée et sortie sur le segment IND 4ifDiscardsAll 3 SUM(ifDiscards) 320 3 1 320 > LOG # Longueur de la file d'attente des paquets en sortie sur l'interface IND 5 coachIfOutQIen 2 ifOutQLen.l 330 5 1 330 > LOG # Somme des Longueurs de la file d'attente des paquets en sortie sur toutes les interfaces du segment IND 6 coachIfOutQLenAll 3 @ SUM(coachIfOutQLen) 670 50 1 670 > LOG # Nombre de paquets retransmis sur l'interface IND 7 coachcpRetransSegs 2 tcpRetransSegs. 0 340 5 1 340 > LOG # Débit d'erreurs sur l'interface IND 8 ifErrors 2 ($(ifInErrors.l+ifOutErrors.l)$t) 290 5 1 290 > LOG # Débit d'erreurs sur le segment IND 9 ifErrorsSUM 3 !SUM(ifErrors) 620 2 1 620 > LOG # Débit moyen d'erreurs sur toutes les interfaces du segment IND 10 ifErrorsMOY 3 (! MOY(ifErrors)*100) 630 5 1 630 > LOG # Débit unicast sur l'interface en entrée et en sortie IND 11 ifUcastPackets 2 (ifInUcastPkts.l+ifOutUcastPkts.l)$t 280 5 1 280 > LOG # Débit multicast sur l'interface en entrée et en sortie IND 12 ifNUPackets 2 (ifInNUcastPkts.l+ifOutNUcastPkts.l)$t280 5 1 280 >NLOG # % d'erreurs sur l'interface par rapport au total des paquets émis ou reçus IND 13 ifErrorsRatio 2 (&ifErrors/(&ifInPackets+&ifOutPackets)) *100 570 5 1570 > NLOG # % moyen sur le segment des erreurs sur toutes les interfaces du segment IND 14 ifErrorsRatioLinkMOY 3 !MOY(ifErrorsRatio) 1220 5 1 1220 > LOG

<Desc/Clms Page number 21>

# % Somme des pourcentages d'erreurs sur toutes les interfaces des liens IND 15 IfErrorsRatioLinkSUM 3 !SUM(ifErrorsRatio) 1220 20 1 1220 > LOG # Quantité d'erreurs d'en-tête et d'adresse sur l'interface. Utiliser pour calculer ipInputErrorsPercent IND 16 ipInputErrors 2$-(ipInHdrErrors.O+ipInAddrErrors.O) 650 5 1 650 > LOG # % d'erreurs d'en-tête et d'adresse sur l'interface IND 17 ipInputErrorsPercent 2 (&ipInputErrors/($-(ipInDelivers.0)))*100 650 5 1 650 > LOG # Somme des pourcentages d'erreurs d'en-tête et d'adresse sur l'interface IND 18 ipInputErrorsPercentOnLink 3 !SUM(ipInputErrorsPercent) 300 5 1 300 > LOG # Indisponibilité d'une machine IND 19 NoDisponibility 2-$t/($-(sysUpTime.O)) 100 1 1 300 > LOG # Somme de l'indisponibilité pour l'ensemble des machines du segment IND 20 NoDisponibilityOnLink 3 !SUM(NoDisponibiity) 150 100 1 300 > LOG # 21/10/97 20:17 fichier : CONFMOD.DOC#version DRAFT

Claims (8)

REVENDICATIONS

1. Procédé de calcul d'indicateur d'un système d'administration de réseau comprenant au moins un sous-administrateur supervisant une partie du réseau, le sous-administrateur comprenant une pluralité de modules permettant la communication avec d'une part les équipements du réseau et d'autre part un administrateur principal, le procédé de calcul étant caractérisé en ce qu'au moins une équation définissant un indicateur et évaluée par un module indicateur du sous-administrateur comprend au moins un attribut d'objet, dont au moins un index est variable, et le procédé comprend - une étape de réception, par le module indicateur, d'une notification transmise par un module de configuration des modèles, cette notification comprenant une adresse d'un équipement et une identification d'une équation représentative d'un indicateur, - une étape d'initialisation, dans laquelle les instances des index variables prennent une valeur d'initialisation ne permettant pas le calcul de l'équation spécifiée.

- une étape de détermination de toutes les instances valides de tous les index variables de tous les attributs de l'équation,

2. Procédé de calcul d'indicateur selon la revendication 1 caractérisé en ce que l'étape de détermination comprend : - une étape de recherche, dans l'équation, d'un attribut appelé attribut fédérateur comprenant le plus grand nombre d'index variable, - une étape d'envoi d'une requête d'interrogation demandant successivement les différentes instances de l'attribut fédérateur, - une étape d'extraction des instances de chaque index variable de l'attribut fédérateur,

<Desc/Clms Page number 23>

- une étape d'envoi d'une requête d'interrogation demandant les instances des attributs de l'équation ayant comme valeur d'index variable, les valeurs extraites dans l'étape précédente, - une étape de mémorisation des instances d'index variables pour lesquelles une instance a été trouvée pour tous les attributs de l'équation

3. Procédé de calcul d'indicateur selon la revendication 1 ou 2 caractérisé en ce que la définition des index dans l'équation, comprend des contraintes limitant le nombre d'instances possibles pour au moins un index variable.

4. Procédé de calcul d'indicateur selon la revendication 2, pris en combinaison avec la revendication 3 caractérisé en ce que le procédé comprend une étape de vérification, permettant de contrôler si les instances des index extraites de l'attribut fédérateur respectent les contraintes spécifiées.

5. Procédé de calcul d'indicateur selon l'une des revendications 1 à 4 caractérisé en ce que le procédé comprend une étape de mise à jour des instances des index réalisée périodiquement.

6. Procédé de calcul d'indicateur selon la revendication 5 caractérisé en ce que l'étape de mise à jour comprend : - une étape d'envoi d'une requête d'interrogation demandant successivement l'instance suivante de l'attribut fédérateur, - une étape de comparaison des instances d'index trouvées avec les instances précédentes des index, - une étape de vérification de la validité d'une part des instances d'index trouvées qui correspondent à des instances précédentes d'index, et d'autre part des instances d'index trouvées qui ne correspondent pas à des instances précédentes d'index,

<Desc/Clms Page number 24>

- une étape de suppression des instances précédentes d'index qui n'ont pas été trouvées ou qui ne sont plus valides.

- une étape d'ajout des instances d'index trouvées et validées.

7. Procédé de calcul d'indicateur selon la revendication 6 caractérisé en ce que l'étape de validation des instances comprend une étape d'envoi d'une requête d'interrogation demandant les instances des attributs de l'équation ayant comme valeurs d'index variable, les instances trouvées dans l'étape précédente.

8. Procédé de calcul d'indicateur selon la revendication 6 ou 7 caractérisé en ce que l'étape de suppression des instances précédentes d'index qui n'ont pas été trouvées ou qui ne sont plus valides comprend : - une étape de marquage des instances d'index validée lors de l'étape de vérification de validité, - une étape de comptage du nombre total d'instance d'index, - une étape de suppression de toutes les instances d'index non marquées, sauf une.