Administration du système d'information :

une certaine déception

Rémy Giraud

Météo France

Remy.Giraud@meteo.fr

Session Admin1

1. Introduction

Le centre de production de Météo-France a déménagé de Paris à Toulouse en 1991. A cette occasion, tous les équipements réseaux ont été renouvelés et une station de supervision réseau a été installée. Nous étions donc dans une situation idéale pour utiliser pleinement le protocole SNMP naissant. Les quatre ans qui nous séparent de 1991 ont vu un certain nombre de déceptions apparaître.

2. La révolution SNMP

a. L'arrivée du protocole

Avec la standardisation du protocole SNMP, le métier de responsable réseau connaissait un profond bouleversement. Avec SNMP, le rôle de pompier ( réparer le plus rapidement possible ) devait céder la place à celui de gestionnaire.

A cette époque, l'association Aristote a mis en place un groupe de travail chargé de l'administration des réseaux. Les participants de ce groupe se sentaient, un peu, une âme de pionnier. Nous avions tous le sentiment que notre métier allait changer. Lors de nos premières réunions, nous avons essayé de définir ce qu'était l'administration des réseaux. A coté de la définition en 5 thèmes de l'ISO, nous pensions qu'avec SNMP, nous allions pouvoir gérer les performances ( statistiques...  ), les configurations...

En 1991, avec les plates-formes disponibles ( Sunnet Manager... ), la lecture et la représentation graphique des objets de la MIB II ne posaient plus de problème, mais pour des opérations plus sophistiquées ( configuration ) les plates-formes montrèrent rapidement leur limite.

Ainsi, lors d'une étude consacrée aux sondes SNMP ( les premières sondes RMON arrivaient tout juste ), nous nous sommes aperçus que :

- l'intégration de nouvelles MIBs n'est pas toujours chose facile ( ! )

- des outils génériques ne sont pas adaptés à l'utilisation de MIBs aussi complexe que la MIB RMON.

Si le premier point est plutôt une affaire classée, le second est de plus en plus d'actualité.

b. Les MIBs supplémentaires

SNMP et les premières MIBs standards ( MIB I et MIB II ) découlent très naturellement de la première ébauche d'un protocole de gestion : SGMP ( Simple Gateway Management Protocol ) et se sont révélés très adaptés à la gestion des statistiques sur les routeurs. Mais pour les hubs, les imprimantes, la MIB II ne correspond pas bien à ces types de matériels. Très vite, le besoin d'objets supplémentaires est apparu. Aujourd'hui, plusieurs dizaines de MIB supplémentaires sont standardisées, sans compter les MIBs propriétaires ! Il y a tellement de MIB différentes que cette foison d'objets devient difficilement compréhensible.

c. Les outils spécialisés

Pour certaines MIBs standards ou propriétaires, les plates-formes SunNet Manager ou HP Open View ne sont pas suffisantes. Il est déjà relativement difficile de rajouter une route statique dans un routeur à l'aide de commandes set SNMP, mais pour la mise en place de filtre dans RMON, il est impossible de la faire sans outils additionnels.

Pour répondre à ce type de problèmes, des logiciels spécifiques RMON sont apparus. Il s'agit là d'outils dédiés à une MIB standard. Mais, les constructeurs d'équipements réseaux se sont également intéressés à ce problème et proposent des outils dédiés à leur matériel qui s'intègre à HP OV ou SunNet.

Outre le coût, parfois prohibitif, de ces outils leur intégration n'est pas homogène et des recouvrements ou des redites sont monnaie courante, ce qui rend leur utilisation dans un cadre opérationnel très délicate.

Après une phase de resserrement de l'offre de n logiciels indépendants vers SNMP, on assiste à nouveau à un éclatement de l'offre ! Il y a bien en dessous un protocole standard SNMP, mais, malheureusement, cela n'a pas permis une réduction des coûts pour l'administration réseaux, bien au contraire. Tous les logiciels propriétaires tournent sur une plate-forme matérielle unique au lieu de n PC.

3. La gestion du système d'information

a. L'offre répond-elle aux besoins ?

On a vu que l'offre produit était presque trop importante, il est donc légitime d'espérer que tous les besoins sont satisfaits.

Si pour les équipements réseaux ( jusqu'au niveau 3 ), c'est effectivement le cas, l'administration du système d'information n'est pas encore correctement traitée.

A part pour les SNMP-phile convaincus, l'administration d'une machine Unix n'est pas sainement réalisable avec SNMP. Certes, il est techniquement possible de rajouter un utilisateur avec un set SNMP, mais la faiblesse, sinon l'absence, de la sécurité dans le protocole, rend cette opération pour le moins hasardeuse.

Le S de SNMP veut dire simple, il ne faut jamais oublier ce que cela signifie. Le but des développeurs de SNMP était de créer un protocole simple et dans la mesure du possible efficace d'où le choix de l'appuyer sur UDP pour ne pas charger les agents et connaître la plus grande diffusion possible. Ils y ont réussi au-delà de leurs espérances. Tant et si bien qu'une tendance à vouloir utiliser SNMP à toutes les sauces s'est développée. On ne peut que se féliciter de disposer d'un protocole standard pour toutes les tâches de gestion, mais encore faut-il que ce protocole soit suffisamment performant pour le permettre. Ce qui n'est sans doute pas le cas.

b. DME, CMIP, SNMPv2

Dès la diffusion du protocole SNMP, ses limites ont été perçues. Au même moment deux initiatives dans deux environnements différents ont cherché à combler les lacunes de SNMP. Après un départ sur les chapeaux de roues, l'OSF pour des raisons technico-mercantiles n'a pas pu mener le projet DME jusqu'à son terme. La voie ouverte par les logiciels pré-DME ( en particulier Tivoli ) semblait assez prometteuse malgré quelques défauts de jeunesse. Le stade pré-DME qui devait déboucher sur une offre normalisée n'a jamais été dépassé...

CMIP, protocole OSI, est à l'opposé de SNMP. Si l'un privilégie la simplicité, CMIP a au contraire choisi l'exhaustivité. Dans les environnements où l'OSI était déjà implanté, CMIP trouve naturellement sa place. Les opérateurs télécom sont par exemple, les premiers utilisateurs de CMIP. Dans l'environnement de l'informatique scientifique, il ne semble pas y avoir d'adhésion à cette norme. Techniquement, le protocole est adapté à la gestion d'équipements plus complexes que SNMP. Mettre CMIP sur un hub 6 ports n'est pas une bonne idée, en revanche si des ressources sont disponibles, les services offerts par CMIP dépassent ceux de SNMP. Donc le protocole est présent, mais un peu comme pour tous les protocoles OSI, le marché ne suit pas.

Vu le succès de SNMP et compte tenu de ses limites, les créateurs de SNMP ont travaillé depuis environ 3 ans à son successeur. Appelé au départ SMP ( le network n'était plus le seul objectif ), la dénomination officielle choisie est SNMPv2. A la lecture de ce nom, il est légitime de penser que SNMPv2 est une suite logique de SNMP et qu'une compatibilité ascendante est présente. Ce n'est pas le cas. SNMPv2 rajoute quelques services en particulier le get-bulk pour une lecture plus efficace de grandes tables et une possibilité de cryptage utilisant DES pour les dialogues entre agents et managers.

Les développeurs souhaitaient aller vite pour profiter au plus tôt de la vague SNMP. Les RFC, nécessaires pour l'adoption par l'IETF de SNMPv2 comme standard, sont prêts depuis un an au moins. Depuis cette date rien ne semble bouger. Il n'est pas certain que ce protocole soit aussi révolutionnaire que SNMP, mais sa promulgation en standard serait tout de même une bonne chose. Quelques agents mixtes v1 et v2 existent ( Cisco offre les deux depuis 1 an environ ) en revanche les managers tel que HP OpenView n'intègrent pas SNMPv2. Certains créateurs de la version 2 proposent de travailler sur une version 1.5 qui elle pourrait être standardisée.

On s'aperçoit donc que pour des raisons très diverses, il n'y a pas ( pour le moment ? ) d'alternative crédible à SNMP !

c. Pendant les travaux, la vente continue !

Comme la nature, le commerce a horreur du vide. Le downsizing, le rightsizing, le reengeneering continuent. Les ordinateurs centraux sont petit à petit remplacés par les systèmes ouverts ( Unix ) ou par d'autres solutions comme Windows NT. Il est beaucoup plus difficile de gérer un environnement de production réparti sur 10 machines Unix que sur un mainframe IBM ou Control Data. La demande en outil d'administration des systèmes et des applications est donc de plus en plus forte. En l'absence de solution normalisée, chacun propose son produit incompatible avec celui du concurrent. Les logiciels comme CA Unicenter ou HP Operation Center permettent de gérer plus ou moins bien les applications et les systèmes sous-jacents.

4. L'exemple de Météo France

Le pré-traitement et le post-traitement du modèle de prévision météorologique de Météo France viennent d'être redéveloppés pour passer d'une machine Control Data sous NOS à un ensemble de machine Unix. Au moment de la définition du projet, il nous est apparu très clairement que les outils Unix classiques ne permettaient par de gérer cet ensemble destiné à la production. En particulier, nous avons recherché des outils qui permettent une présentation de l'état de l'application pour les pupitreurs afin que ceux-ci prennent les décisions les plus appropriées. Nous voulions avoir un poste de travail où l'ensemble de ces informations soit présenté de manière graphique. Nous recherchions donc un SNMP pour les systèmes et les applications. Malheureusement, et nous le savions déjà, ça n'existe pas !

Le choix s'est porté sur une offre HP, Operation Center. Ce logiciel est la version 0.5 de ce que devrait être le logiciel de gestion d'application normalisé. Il est inutile de décrire davantage quels sont les inconvénients d'utiliser des solutions propriétaires par rapport à des solutions standards... mais et je le regrette, nous n'avons pas d'alternative.

5. Le temps des regrets

Alors qu'en 1991, tout semblait prêt pour une mise en place progressive des normes et des outils pour une gestion complète du système d'information ( réseaux, systèmes et applications ) force est de constater que nous en sommes bien loin. Certes le marché est très porteur, la demande est très forte, les séminaires sur la gestion du système d'information sont presque aussi nombreux que pour Internet, mais en fait qui est gagnant ?