Gérer un réseau d’entreprise a toujours été un casse-tête pour un administrateur. Mais, avec la montée en puissance d’Internet, des systèmes de messagerie, des progiciels de gestion intégrés (ou ERP), conjuguée à l’apparition de nouveaux systèmes d’exploitation (Linux et Windows 2000, notamment), cette mission peut virer au cauchemar. Pourtant, sans pour autant abandonner l’infrastructure existante, et en tenant compte de l’historique des événements survenus sur le réseau, l’administrateur doit tout entreprendre pour faire évoluer son service de supervision. Cette opération, la plus transparente possible pour l’utilisateur, implique une absence de rupture.
Ancien et nouveau systèmes devront alors cohabiter, au moins jusqu’au ‘ recettage ‘ de la nouvelle solution. Les spécialistes de l’administration insistent, en outre, sur la nécessaire récupération de la connaissance accumulée avec le précédent système de supervision. Cette dernière est surtout concentrée sur les sondes logicielles (agents) chargées de surveiller les équipements, des agents qui sont le plus souvent personnalisés.
Atos fait évoluer ses outils
L’exemple d’Atos est significatif. En 1998, sa division de production non mainframe s’est retrouvée dans l’obligation de faire évoluer ses outils de supervision, afin de faire face à deux problèmes majeurs. Le premier était lié au passage à l’an 2000. Le second concernait l’évolution de sa plate-forme. Cette dernière avait, en effet, été rachetée et ne prenait plus en compte les nouveaux systèmes d’exploitation ni les nouvelles applications. Ne pouvant se permettre de développer ce qui était déjà en production, l’outil sélectionné devait donc reprendre l’existant, avec un minimum de travail et de personnalisation.
Enfin, la solution retenue devait assurer la pérennité des investissements sur plusieurs années, grâce, entre autres, à une capacité de montée en charge très importante. Ce point a été jugé essentiel, compte tenu des investissements consentis par cette division d’Atos dans le projet. De plus, cette entité devait respecter les contrats SLA (Service level agreement) passés avec ses clients sous peine de sanctions financières fortes. Rien ne devait donc être laissé au hasard. ‘ Mon équipe gère plusieurs centaines d’environnements qui sont, de surcroît, tous différents. Certains sont directement hébergés dans nos bunkers, tandis que d’autres le sont encore chez le client. Dans ce cas, cela nécessite, de la part de nos ingénieurs, une supervision à distance. A cela s’est ajoutée l’arrivée de Windows NT, l’explosion d’Unix avec AIX, HP-UX, Solaris, Escala, SCO, etc. Le superviseur idéal devait donc prendre en compte tous ces systèmes d’exploitation, sans oublier les SGBDR et autres progiciels intégrés ‘, déclare Michel Galliot, directeur de la division de production non mainframe d’Atos. L’intégrateur a donc opté pour Unicenter TNG, de Computer Associates. Ce dernier ayant racheté Polycenter – ancien superviseur d’Atos – à Digital-Compaq, l’éditeur américain à proposé de nombreux outils pour récupérer les informations PolyCenter sous Unicenter TNG.
Pour réussir ce type de migration, l’étude approfondie du système d’information reste une étape incontournable. Une entreprise peut décider de mener à bien cette opération seule. Dans la pratique, l’assistance d’une société tierce se révèle pourtant souvent utile. Il faut, en effet, commencer par répertorier l’intégralité des équipements composant l’infrastructure du système d’information. Cette opération comprend le recensement aussi bien des matériels réseaux et des progiciels intégrés que des bases de données ou des systèmes d’exploitation. Ces procédures permettent de récupérer les historiques, les inventaires ou la topologie réseau. Pour y parvenir, l’entreprise doit s’appuyer sur le travail accompli avec son superviseur existant. Il peut être complété par des outils tiers pour reprendre des informations sur le matériel (comme des commutateurs, des routeurs ou des serveurs). Ces données vont, par la suite, rendre possible la définition d’une vue précise de l’infrastructure du système d’information. En ce qui concerne les applications et les systèmes d’exploitation, l’analyse préalable à la migration nécessite la prise en compte de deux aspects. Le premier se rapporte aux événements et aux erreurs directement liées aux applications. Le second consiste à superviser leurs performances tout au long de leur fonctionnement.
L’approche la plus fréquemment adoptée consiste à surveiller les applications (bases de données, serveurs de messagerie et progiciels intégrés) et l’infrastructure technique (réseaux locaux, réseaux étendus ou serveurs matériels) séparément. Cette procédure pragmatique ne garantit cependant pas nécessairement une administration proactive. Le gestionnaire réseau doit plutôt parer au plus pressé et corriger le dysfonctionnement le plus rapidement possible.
chaque environnement ses règles d’alerte
Pour diminuer ces temps de réaction, les outils de supervision proposent, en standard, des listes de tâches qui peuvent être automatisées ou déclenchées en cas de dépassement de seuil. L’administrateur a ensuite la possibilité de les personnaliser pour les adapter à ses besoins. Par exemple, au cas où une base de données Oracle viendrait à manquer d’espace disque, une alerte serait alors déclenchée, afin de prévenir, non seulement l’administrateur, mais également la personne en charge des achats de ce matériel. Mais, toutes ces opérations correctives n’ont de sens que si les événements surveillés sont réellement pertinents. C’est là que toute la compétence et l’expérience des ingénieurs en charge de la supervision se révèlent de précieux atouts. En effet, comment sélectionner parmi les mille événements de Windows NT ceux qui ont une relation directe avec le système d’information de l’entreprise ?
BMC, Bull, Computer Associates, HP et Tivoli répondent à cette problématique en implantant des agents sur leurs consoles. Plus ou moins intelligents, ces derniers autorisent un filtrage des événements en fonction de certaines règles préalablement fixées et assez simples à définir. Par exemple, pour être averti lorsque la puissance CPU du serveur Oracle est proche de son utilisation maximale, l’administrateur définira une règle comme suit : ‘ If % CPU > 80 Then “action” ‘.
Dans cette règle, le terme ‘ action ‘ correspond à ce que souhaite provoquer le superviseur en cas de déclenchement du seuil d’alerte. Cela peut aller de la simple information émise sur la console à l’envoi de message transféré à un terminal de radiomessagerie ou message SMS (Short message service) transmis sur un téléphone mobile.
Ces règles définissent des contextes, qui correspondent, en fait, à des profils propres à l’environnement.
Tous les agents n’ont pas la même faculté d’adaptation
Ces profils existent déjà pour les équipements surveillés. Il convient donc de pouvoir les conserver. Pour cela, l’administrateur dispose d’outils spécifiques. BMC propose ainsi une stratégie bien précise pour récupérer la configuration des modules de connaissances Patrol qui ont été personnalisés. Il faut employer l’utilitaire upgrade_db. La reprise des informations de personnalisation propres à la console s’effectue simplement en copiant les fichiers de l’ancienne version sur la nouvelle.
Il est toutefois nécessaire de vérifier auprès de l’éditeur que les moutures des produits permettent d’effectuer cette opération sans générer d’incident. L’historique des événements est aussi réexploitable par l’intermédiaire de l’utilitaire Histconv. Ce point est essentiel. En effet, une partie de la compréhension du système d’informations de l’entreprise repose sur les historiques générés à partir de la ou des consoles. Il arrive pourtant qu’il soit impossible de reprendre cette version. Ainsi chez HP, le passage du module logiciel IT/Operation à VantagePoint (tous deux appartenant à la suite OpenView, de HP) entraîne la perte des historiques. En revanche, le constructeur californien a soigné la fonction de la récupération des agents. Son objectif est, bien entendu, de faire migrer une partie de ces consoles de supervision Unix (IT/Operation HP-UX, entre autres) sous Windows NT et 2000 (avec VantagePoint).
De son côté, Tivoli a opté pour une tout autre approche. L’éditeur texan, filiale d’IBM, dispose d’agents indépendants des versions du superviseur. En cas de migration, il n’est donc plus utile de se préoccuper de ces derniers. Ils se mettent, en effet, automatiquement à niveau en allant consulter le serveur de supervision qui leur est attaché. Tivoli a profité de cette spécificité pour bâtir une véritable stratégie de déploiement des agents. Ils sont, le plus souvent, installés de façon statistique. Leur configuration et leur mise en fonction sont très lourdes à gérer. L’approche de Tivoli, avec son TMA, consiste à déployer un agent générique qui sera ensuite configuré par le serveur. Cet agent servira aussi de relais pour les déploiements des autres TMA. Cette stratégie prend le nom de One Touch Management. Ne pouvant réussir seul dans cette entreprise, Tivoli a passé de nombreux accords avec des éditeurs et des constructeurs afin qu’ils installent en standard les TMA dans leurs produits. 3Com, Compaq, Intel, Microsoft et Novell ont déjà rejoint Tivoli.
asser d’une action réactive à une gestion proactive
D’autres sociétés, comme Candle, Compuware, Loan System ou Veritas, ont une offre d’agents de supervision d’applications dédiées. Ils proposent des solutions pour Notes, Exchange, Oracle, ou encore, SAP R/3. Quels que soient la technologie d’agent retenue et le fournisseur, toutes les informations seront remontées vers la console centrale. La mise en place d’une telle solution n’est pas encore totalement satisfaisante pour le directeur du système d’information.
En effet, avec ces agents, l’administration reste réactive. Pour passer à une gestion proactive, l’approche métiers s’impose. ‘ Dans un premier temps, nous nous sommes attachés à récupérer le travail accompli avec l’ancienne plate-forme. Notre objectif, à terme, est de pouvoir créer des vues métiers pour chacun de nos clients ‘, explique Michel Galliot.
Mesurer l’impact d’une panne sur le comportement du réseau
C’est ce que proposent les consoles de Bull, Tivoli, Computer Associates et HP. Elles donnent ainsi la possibilité de connaître réellement l’impact d’une panne pour l’entreprise.
Dans le schéma de supervision traditionnelle, la panne d’un routeur, par exemple, pourra être anticipée par l’administrateur réseau. Celui-ci ne dispose que d’une vue horizontale du système d’information (en l’occurrence, la couche réseau).
Il ne peut donc pas mesurer l’impact que cette panne a sur le comportement du réseau.
La vue métiers, en revanche, permet de savoir si ce dysfonctionnement a une incidence grave, comme l’arrêt des prises de commandes. Le temps d’intervention doit alors être le plus court possible. Cette vision du système d’information est la prochaine étape des administrateurs. Les travaux d’Hercule ne font que commencer…
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
