Entretien avec le concepteur de la SmartSuite
Qu’est-ce que la SmartSuite for OpenMaster ?
La SmartSuite est une ligne de logiciels destinés à la supervision normalisée des réseaux.
Et OpenMaster ?
OpenMaster est la plate-forme d’administration de réseaux proposée par Evidian, une société du groupe Bull. OpenMaster offre une infra-structure de communication CMOT permettant de dialoguer avec un réseau en SNMP ou en CMIP ainsi que toute une gamme d’applications et de services, de la présentation du réseau sous forme de cartes graphiques à la journalisation et à la gestion des alarmes en passant par la compilation des documents RFC et GDMO.
Qu’est-ce qu’un réseau dont la supervision est normalisée ?
La supervision d’un réseau est dite normalisée quand tous les composants physiques et logiques du réseau - les équipements qui le constituent et les liaisons entre ces équipements - sont accessibles par SNMP ou CMIP. Un réseau SNMP ou CMIP a l’avantage de garantir un accès standard à de multiples composants qui sinon ne seraient gérables que par des logiciels propriétaires.
Dans un système de gestion normalisée on trouve des superviseurs et des agents. Un superviseur exécute à la demande des requêtes sur le réseau pour obtenir une information ou déclencher une action. Il reçoit aussi spontanément des notifications d’événements. Un agent est une entité qui se trouvent au niveau de chaque élément du réseau et dont le rôle consiste à interpréter les requêtes des superviseurs et à les traduire pour l’élément qu’il interface. Il prend aussi en charge la remontée des événements vers les superviseurs. Ce dialogue protocolaire repose sur une vision uniforme des éléments du réseau appelée une MIB (Management Information Base).
Un superviseur peut être une application interactive avec un opérateur comme un synoptique de contrôle de l’état des équipements et de leurs liaisons ou une tâche de fond tel qu’un service de journalisation sur disque des alarmes.
Un agent peut être un composant logiciel directement intégré à un équipement du réseau ou un service indépendant relié à un ou plusieurs éléments du réseau. Un agent est dit embarqué ou déporté.
La partie de la MIB correspondant à un élément du réseau, physique ou logique, un équipement comme un service, est décrite par le détail dans des documents normalisés appelés RFC (Request For Comment) dans le monde SNMP et GDMO (Guidelines for Definition of Managed Objects) dans le monde CMIP. A chaque équipement ou service du réseau correspond un RFC ou un GDMO. Certains documents sont normalisés et édités par l'OSI (Open System Interconnexion) ou l'IETF (Internet Engineering Task Force), d’autres sont fournis par les équipementiers.
Tout élément d’un réseau doté d’un agent SNMP ou CMIP peut-être immédiatement géré par OpenMaster et donc par la SmartSuite.
SNMP et CMIP, rapidement ?
SNMP (Simple Network Management Protocole) est un protocole d'administration de réseau de la famille TCP/IP. Approuvé en 1988 par l'IAB (Internet Activities Board), SNMP a été adopté dès 1989 par de nombreux constructeurs et est devenu à ce jour un standard très répandu.
CMIP (Common Management Information Protocol) est un protocole OSI de niveau 7. Résultat d’une collaboration internationale entre les grands équipementiers, les opérateurs de réseaux et les grands comptes de l’industrie informatique.
SNMP est un produit de la culture Unix. CMIP est plus destiné aux systèmes propriétaires.
En une requête SNMP, on peut obtenir la valeur d’un paramètre d’un équipement. En une seule requête CMIP, on peut obtenir une sélection des attributs de tous les équipements du réseau qui répondent à certains critères. SNMP ne peut gérer que des données simples (entiers, textes) alors qu’il n’y a aucune limite quant à la complexité des données gérables en CMIP.
Si CMIP est bien plus riche que SNMP, il est d’autant plus difficile à mettre en œuvre. Dans les environnements où l'OSI était déjà implanté, CMIP trouve naturellement sa place. SNMP règne sur le réseau internet. Si les opérateurs télécom sont les premiers utilisateurs de CMIP, les scientifiques et les universitaires ne semblent pas adhérer à cette norme.
CMOT (CMIP Over TCP/IP) est une implémentation du service CMIS sans les couches inférieures du modèle OSI, sur TCP/IP.
Quel est le rôle d’OpenMaster dans une solution d’administration normalisée d’un réseau ?
OpenMaster propose une approche centralisée autour d’un infra-structure de communication CMOT. Toutes les informations échangées entre les éléments du réseau et les applications sont décrites dans des GDMO. Toutes les requêtes et toutes les notifications d’événements sont véhiculées en CMIP via les agents intégrateurs SNMP et CMIP.
OpenMaster donne toujours une vision CMIP du réseau. Les agents intégrateurs traduisent les opérations vers les éléments du réseau et convertissent les notifications d’événements sous leur forme normalisée.
MISS est un service qui compile les documents GDMO et RFC pour la plate-forme. MISS peut encoder et décoder les données définies en ASN.1/BER et distribuer leurs définitions à d’autres applications.
L’offre d’OpenMaster semble déjà complète, qu’apporte la SmartSuite ?
Le principe moteur des plate-formes développées par Bull, HP ou IBM, était de toujours échanger l’information entre les services et les applications en CMOT via une infra-structure de communication.
Cette approche représentait un progrès par rapport au dialogue point à point dicté par les protocoles SNMP ou CMIP. Avec OpenMaster, une application peut interroger les agents en CMIP via l’infra-structure sans se préoccuper d’ouvrir une connexion et de gérer l’échange des données. Seulement CMIP est particulièrement exigeant en ressources. Tout le dialogue est encodé en BER et les applications passent beaucoup de temps à encoder et à décoder les informations qu’elles s’échangent. De plus, dans la pratique, la même application est souvent dupliquée sur tous les postes de surveillance du réseau et les mêmes requêtes viennent inlassablement surcharger le trafic et les agents, au risque de nuire au fonctionnement du réseau. Enfin, toutes les informations nécessaires à l’administration d’un réseau ne sont pas forcément accessibles en SNMP ou CMIP et il est indispensable de pouvoir interroger des bases de données ou d’autres programmes. Le credo du tout CMIP est finalement lourd à porter.
La SmartSuite repose sur des concepts radicalement différents. Tous les services et toutes les applications dialoguent via un bus de communication directement sans encodage dans leur langage de programmation. L’infra-structure n’est utilisée que comme canal d’accès aux équipements du réseau, jamais pour échanger des données entre programmes. Un seul service, l’Explorer, interroge le réseau, les bases de données ou d’autres processus et notifie les autres composants de la SmartSuite. Les requêtes sur le réseau sont donc centralisées et limitées au strict minimum. De plus, ce service est capable d’enrichir l’information en corrélant les données collectées et en les filtrant. Cette approche à le double avantage de réduire considérablement le trafic et les temps de calcul pour la plate-forme, les agents sur le réseau et les applications clientes, tout en offrant une interface banalisées aux applicatifs de la SmartSuite.
Convaincant ! Et les applications ?
La SmartSuite a été conçue avec en ligne de mire la performance, l’adaptabilité et la fiabilité. Elle a été élaborée en réponse aux contraintes réelles d’une solution d’administration d’un réseau. Elle a évolué sans cesse à l’initiative de ses utilisateurs.
Tous les composants de la Smartsuite sont étonnamment configurables. Sans aucun développement logiciel supplémentaire, la SmartSuite peut d’emblée superviser de grands réseaux hétérogènes. Le soin apporté à la qualité ergonomique et esthétique de la SmartSuite est patent. Sa robustesse a été démontrée par les mises à l’épreuve exhaustives de ses utilisateurs et la confiance qu’ils lui portent.
Une description rapide des différents composants de la SmartSuite ?
La Smartsuite se décline en cinq produits principaux et une série d’outils :
Explorer - surveillance des éléments du réseau (MIB), d'une base de donnée et de processus.
Mapper - supervision et contrôle du réseau sous la forme de cartes graphiques animées.
Logger - journalisation, analyse et traitement des alarmes.
Simulator - simulation et contrôle opératoire des éléments du réseau.
WebIt - passerelle PHP entre le Web et la SmartSuite.
Broker - dialogue inter-processus via un bus de communication.
Qualifier - filtrage du flot d’événements émis par le réseau.
MiMe - gestion locale d’une MIB en mémoire.
MIB Tools - navigation, visualisation, envoi d’opérations et de notifications sur un réseau.
Toolkit - ensemble de plus de 100 classes d’objets pour le développement d’extensions spécifiques.
Plus de détails sur les applications ?
L’Explorer filtre les événements et surveille la MIB pour le compte d’autres applications comme le Mapper ou le Logger. Il peut aussi interroger une base de données ou contrôler un autre processus. Souvent l’Explorer pallie aux défaillance d’implémentation des protocoles par les agents. L’Explorer est enfin un véritable système de corrélation capable d’analyser et de relier toutes les informations collectées.
L’association des agents intégrateurs et de MISS avec l’Explorer assure que virtuellement tout composant d’un réseau avec une interface SNMP ou CMIP peut être complètement administré par la SmartSuite. Si un équipement ou une application n’a pas d’interface normalisée, l’Explorer est capable de lancer un processus quelconque et de filtrer son flot de sortie. Cette fonction peut servir à surveiller des éléments dotés d’une interface Corba ou ASCII.
Le Mapper permet de représenter un réseau de façon graphique. Il peut afficher des figures simples comme des polygones, des cercles ou des icônes, mais aussi des objets composés comme des histogrammes et des compteurs. Il peut tracer des liens entre toutes les figures. Les objets graphiques sont animés en changeant leurs propriétés en réponse à des messages envoyés par l’Explorer ou toute autre application. Le Mapper peut aussi lancer des actions internes ou externes à partir de menus contextuels.
Le Qualifier collecte les événements émis sur la plate-forme ou déjà filtrés par l’Explorer et génère des alarmes corrélées qui sont journalisées par le Logger. Son rôle est d’enrichir le flot des événements tout en le réduisant.
Le Logger conserve tout type d'alarme et d'événement. Son interface graphique permet de consulter et de traiter le flot des événements en direct, les journaux des alarmes qualifiées, les corrélations entres les événements et les alarmes, les événements et les alarmes historiques. Il comporte une interface ouverte vers un système de gestion de tickets d’anomalie. Le Logger peut qualifier les événements de lui-même ou traiter les alarmes envoyées par le Qualifier ou un autre moteur de corrélation plus sophistiqué.
Le Simulator peut émuler tout élément d’un réseau et agir comme un processeur de commande sur les équipements. C’est un composant essentiel pour valider et démontrer des solutions, entraîner les opérateurs dans des conditions extrêmes ou organiser et contrôler les opérations sur le réseau.
Le WebIt permet l’accès complet aux services et aux applications de la SmartSuite via un serveur web. Le dialogue est programmé en PHP. Le WebIt ajoute une tout autre dimension à la SmartSuite avec la possibilité d’utiliser toutes les technologies du web comme les serveurs Apache et IIS, PHP, les formats HTML et XML, les translateurs XSL, .NET, Java, JavaScript et Flash, etc. Avec le WebIt, sans connaissance particulière des protocoles et de leur mise en œuvre, des développeurs web peuvent exploiter toute la puissance des services de la SmartSuite et exprimer leurs compétences en produisant rapidement une infinité d’applications allant de la simple génération de documents HTML à des plugins Java ou Flash analysant un flot XML.
Et vous proposez aussi une boîte à outils ?
L’objectif de la SmartSuite est de fournir le moyen de monter une solution d’administration d’un réseau sans aucun développement supplémentaire. Toutefois, la même boîte à outils qui a servi à développer les applications de la SmartSuite est disponible pour l’intégration transparente d’extensions spécifiques. A l’extrême, on peut écrire toute une application indépendante pour combiner plusieurs carte animées, l’affichage des alarmes et toute une série de boutons de contrôle dans un seul synoptique.
Supervision des tours de contrôle du trafic aérien passager (DFS)
Quel est le schéma général d’une solution construite autour de la SmartSuite ?
Je vous renvoie au document décrivant l'intégration de la SmartSuite à OpenMaster, à Oracle, au système de gestion des tickets d'anomalie ARS de Remedy et à Apache pour plus de détails.
Un exemple illustrant tous les bénéfices apportés par la SmartSuite ?
La console centrale de supervision d’un réseau d’ordinateurs doit afficher le taux d’occupation moyen de tous les disques des utilisateurs. En cas de dépassement d’un certain seuil, l’opérateur doit recevoir une alerte visuelle et sonore.
Tous les ordinateurs sont équipés d’un agent SNMP qui peut retourner le type et le taux d’occupation de chacun des disques.
Commençons par le résultat recherché. A l’aide de l’éditeur du Mapper, on place dans une carte une figurine représentant un disque surmonté d’un pourcentage.
On spécifie l’animation du disque en associant trois messages au changement de la couleur de l’intérieur du disque et de son label : occupationMoyenneDesDisquesCorrecte au vert, occupationMoyenneDesDisquesImportante à l’orange et occupationMoyenneDesDisquesSaturée au rouge. Tous ces messages afficheront aussi la moyenne calculée en changeant la propriété correspondante de la figure. On associe aussi le message occupationMoyenneDesDisquesSaturée à l’émission d’un alerte sonore.
A l’aide de l’outil Stimulator livré avec le Mapper, on peut tester le comportement de la carte hors connexion au réseau en lui envoyant les différents messages programmés.
Pour programmer l’interrogation du réseau, on configure une sonde dans l’Explorer qui va en une seule requête CMIP parcourir périodiquement tous les ordinateurs du réseau et retourner le taux d’occupation de chacun de leurs disques. Cette sonde va alimenter une autre sonde qui va collecter toutes les réponses et calculer la moyenne recherchée. Une fois la dernière réponse reçue, cette sonde va comparer la valeur obtenue avec trois seuils donnés et émettre vers les applications qui l’ont demandé le message convenu accompagné de la valeur calculée.
Il ne reste plus qu’à associer le fichier contenant les deux sondes avec la carte graphique et à démarrer l’animation de la carte pour contrôler le résultat.
Si on enclenche le traçage de l’activité de l’Explorer et si on lance la même carte dans un autre Mapper, on constate que la charge sur le réseau reste inchangée.
On peut facilement enrichir la représentation graphique pour, par exemple, afficher un rond clignotant en haut à droite du disque lorsque les disques sont saturés. On peut aussi journaliser une alarme. On peut même faire dépendre le seuil d’alerte d’un paramètre spécifique extrait d’une base de données. Les possibilités sont immenses. Enfin, dans le but de valider les réactions des opérateurs, on peut programmer le Simulator pour générer des comportements de crise sans perturber pour autant le réseau réel.
Encore un détail, les fichiers décrivant les cartes, les sondes ou les simulations sont de simples fichiers ASCII faciles à générer par programme. Une fois un prototype au point, qui voudrait éditer à la main des centaines, voire des milliers de fichiers souvent identiques sauf pour le texte d’un label ou la désignation d’un équipement sur le réseau ?
Et sur le Web ?
Pour afficher la même information dans un navigateur web, un simple programme en PHP de quelques lignes suffit pour demander à l’Explorer de charger les mêmes sondes et formater la réponse en HTML. Tout le dialogue entre le serveur web et la SmartSuite est transparent pour le navigateur.
La SmartSuite est-elle liée à OpenMaster ?
La SmartSuite est complètement développée en SML (System Management Language), le langage de programmation spécifique à OpenMaster. La plate-forme inclut des agents intégrateurs SNMP et CMIP qui traduisent les opérations vers les éléments du réseau et convertissent les notifications d’événements sous une forme normalisée. Le dialogue avec les éléments du réseau est donc totalement pris en charge par OpenMaster. De plus, le service standard MISS compile les documents GDMO et RFC et peut fournir leurs définitions à d’autres applications par programme. Il est aussi chargé de l’encodage et du décodage des données définies en ASN.1/BER.
La SmartSuite dépend donc complètement des services de base fournis par OpenMaster mais d’aucune de ses applications. On peut noter que la SmartSuite est parfaitement compatible avec les produits standards d’OpenMaster et peut même les enrichir.
Sur quels systèmes la SmartSuite est-elle disponible ?
La SmartSuite est disponible sur les systèmes supportés par OpenMaster - AIX, Solaris et Linux.
Dans quels types de réalisations la SmartSuite a-t-elle été utilisée ?
Nos logiciels sont au cœur de plusieurs systèmes de surveillance de grands réseaux en exploitation en Allemagne.
Réseau du téléphone fixe (ARCOR)
Avec des références dans le trafic aérien passager (Deutsche Flugsicherung) comme dans les réseaux de téléphonie fixe (Arcor) et mobile (Die Bahn, T-Mobile), la SmartSuite a démontré sa fiabilité et son adaptabilité.
 |
 |
 |
 |
|---|
Plus de détails sur ces réalisations ?
DFS - CMMC - Trafic aérien passager • Supervision des salles de contrôle • 4 sites surveillant de nombreux types d’équipements (DEC, MatixE7, Cisco) et jusqu’à 10 mandataires ATC pour la supervision d’applications • 4.000 objets gérés • 6 opérateurs.
DFS - MaC/S - Trafic aérien passager • Supervision des radars • 1 site surveillant 29 radars répartis sur toute l’Allemagne • 40.000 objets gérés • 18 opérateurs.
DFS - Tower - Trafic aérien passager • Prototype surveillant 3 tours de contrôle • 17 tours de contrôle sur toute l’Allemagne • 100.000 objets gérés • 60 opérateurs.
Arcor - IFM-T - Réseau du téléphone fixe • Remplacement de 14 types de systèmes de gestion • Vue topologique et surveillance du réseau sur toute l’Allemagne • Corrélation, journalisation et gestion des alarmes • Technologies PDH, SDH, WDM, DSL et ISDN • 10.000 éléments avec 110.000 équipements gérés pour un total de plus de 1.000.000 de points de terminaison logiques et physiques sur 2.420 sites • 90 opérateurs.
Die Bahn - IFM-G - Réseau GSM/R • Remplacement de 6 systèmes de gestion • Surveillance du réseau sur toute l’Allemagne • Journalisation et gestion des alarmes • 2.600 stations radio GSM gérées • 30 opérateurs.
Quel a été le rôle d’inWay dans ces réalisations ?
inWay se limite au développement des applications et des services de la SmartSuite. Les solutions sont généralement montées par des intégrateurs et des prestataires de services.
inWay ne vend en principe que des licences d’exploitation de la SmartSuite.
Avez-vous un partenaire privilégié ?
Toutes les réalisations basées sur la SmartSuite sont l’aboutissement d’une longue collaboration avec Steria-Mummert Consulting, notre partenaire en Allemagne.
Nous recherchons une association équivalente en France.
Et en cas de défaillance d’inWay ?
Etant donné l’importance de la SmartSuite pour les entreprises qui ont fondé l’administration de leur réseau sur nos produits, si pour une quelconque raison inWay ne pouvait plus en assurer la pérennité, l’intégralité des sources serait transmise par Logitas, qui en est le dépositaire, à toute société en possession d’un contrat de maintenance en cours.
Par ailleurs, à la demande de plusieurs clients, Steria-Mummert a depuis plusieurs années toute une équipe de spécialistes parfaitement formés par nos soins à l’organisation interne du code de la SmartSuite.
