IBM Tivoli

Tivoli [Tiv] est le nom d'une gamme de logiciels d'administration éditée par IBM. A l'origine, ces produits étaient développés, depuis 1989, par l'éditeur américain Tivoli Systems, devenu depuis 1996, la branche d'IBM dédiée aux logiciels d'administration de réseaux, de systèmes et d'applications. Dans les sections suivantes, nous détaillons l'archi-tecture d'un système de supervision IBM Tivoli (version 6.X) [GBS+05] et nous présentons deux exemples de passage à l'échelle avec cette infrastructure.

2.4.1.1 Architecture

Un environnement de supervision IBM Tivoli est constitué d'un ensemble de logiciels paramétrés et congurés pour orir un service de gestion cohérent. La gure 2.11 illustre les composants typiques d'une infrastructure IBM Tivoli. Les principaux composants de cette infrastructure peuvent être classés en quatre parties :

Fig. 2.11  Architecture d'IBM Tivoli [GBS+05]

La couche présentation. Cette couche regroupe principalement des clients de type Ti-voli Enterprise Portal (TEP) Browser / Desktop. Un TEP est un client Java qui établit une connexion entre un TEPS Tivoli Tivoli Enterprise Portal Server (TEPS) et les consoles d'administration. Le TEPS est responsable de l'achage et de la présentation des données de supervision. Il requiert l'installation d'un serveur web propriétaire IBM pour acher les pages web présentant les données de supervision. Il établit une connexion permanente avec le TEMS an de disposer des données de surveillance. De plus, il requiert une connexion à l'entrepôt de données de IBM Tivoli (Tivoli Data Warehouse) pour accéder aux données historiques liées aux ressources administrées.

La couche supervision et contrôle. Cette zone de l'infrastructure Tivoli est primor-diale pour la collecte des données de gestion. Elle inclut au moins un TEMS (Tivoli Enterprise Monitoring Server) et optionnellement un TEC (Tivoli Enterprise Console event synchronization). Le TEC est le composant qui assure la fonction de gestion des évènements (synchronisation, publication, etc.). Quant au TEMPS, il constitue l'épine dorsale de l'architecture d'IBM Tivoli. Il représente le point de collecte et de contrôle des informations de gestion envoyés par les agents. Il assure le suivi des noti-cations de présence des agents qui lui sont connectés. Il permet également de stoker les règles de gestion. Un TEMPS peut coexister avec d'autres de ses semblables. Des TEMS distants peuvent être rajoutés pour faciliter le passage à l'échelle.

Gestion des données. Cette partie de l'architecture englobe les composants responsables de la gestion de la persistance et de l'archivage des données de gestion. Le composant TDW Tivoli Data Warehouse est le composant moteur de ce module. Il représente l'entrepôt de données dans lequel sont sauvegardées toutes les données. Se rajoutent à ce composant deux agents, un agent WPA (Warehouse Proxy agent) et un agent S&P (Warehouse Summarization and Pruning agent). Un WPA a pour mission la collecte et la consolidation des informations de gestion et les transférer à l'entrepôt de données, alors qu'un agent S&P s'occupe de l'agrégation et la purication des données de gestion. Il est recommandé d'installer l'agent S&P sur la même machine que l'entrepôt de données à cause de l'éventuel volume important de données à échanger et à traiter.

La couche agents TEMA. Les agents TEMA (Tivoli Enterprise Management Agent) sont installés au niveau des systèmes administrés. Ils assurent la collecte des données de gestion et initient la notication du serveur d'administration pour indiquer leur présence. Ils communiquent directement avec le TEMS mais peuvent également, si l'administrateur le souhaite, communiquer directement les données de supervision à l'agent Warehouse Proxy. Transférer les donnés de supervision d'un TEMPS distant à l'entrepôt de données se fait rarement et est conseillé par IBM comme un dernier recours.

Il existe plusieurs types d'agents TEMA. On peut trouver des agents spécialisés par systèmes d'exploitation (Windows, Linux, Unix, etc.) ou des agents applicatifs (DB2 Agent, Oracle Agent, MS SQL Agent, etc.). Tivoli propose aussi des agents d'intégration (adaptateurs) qui permettent de récupérer des données de gestion à partir de versions antérieures d'agents IBM Tivoli. Il existe également les agents dits "universels", qui permettent à des stations de gestion Tivoli de communiquer avec des systèmes patrimoniaux.

L'assemblage de ces trois modules forme l'environnement de supervision IBM Tivoli. Cet environnement est généralement recommandé pour des petites et moyennes installa-tions (environ 250 ressources administrées). Pour de telles congurainstalla-tions IBM préconise deux agents par ressource administrée, à savoir 500 agents. Nous allons voir dans la section suivante si on peut dépasser ce chire.

2.4.1.2 Passage à l'échelle

Dans cette section, nous présentons deux exemples de passage à l'échelle de l'infra-structure Tivoli, avec respectivement 1500 puis 3000 ressources administrées. Dans les deux scénarios présentés, nous considérons qu'une instance de l'environnement Tivoli est composée des éléments suivants :

 un niveau d'instrumentation représenté par les agents Tivoli,

 un niveau de consolidation intermédiaire des informations de gestion représenté par les TEMS distants,

 un niveau de consolidation global représenté par le TEMS,

 un niveau d'archivage et d'historisation des informations de gestion représenté par le serveur TDW,

(a) Gestion d'un parc de moins de 1500 ressources (b) Gestion d'un parc de 3000 ressources

Fig. 2.12  IBM Tivoli : Architecture de gestion à large échelle 2.4.1.3 Gestion d'un parc de moins de 1500 ressources

. Un environnement d'administration Tivoli peut supporter la gestion de parcs allant jusqu'à 1500 unités administrées. La gure 2.14 décrit le modèle globale de déploiement dans de tels scénarios. L'interconnexion d'un TEMS principal et des TEMS distants produit une topologie d'administration hiérarchique. Les TEMS distants interagissent localement avec leurs agents, et diusent ensuite les informations collectées au TEMS principal. Ce mécanisme permet d'avoir une vue synoptique de l'ensemble du réseau. Cette vue sera par la suite transmise au composant TEPS.

Pour réussir une installation large échelle de Tivoli, IBM recommande :

 une sélection rigoureuse des attributs pertinents des ressources à administrer,  une installation de 500 agents (chire maximum recommandé par un serveur

d'ad-ministration IBM Tivoli) et de 10 TEMs,

 de faire très attention à la sélection de l'infrastructure matérielle et réseau (e.g. topo-logie, latence, pare-feu, etc.). Une installation large échelle requiert une infrastructure matérielle plus lourde que celle requise pour une petite ou moyenne échelle.

 un déploiement sur des machines séparées des composants TDW et WPAgent, res-ponsables respectivement de la collecte des données de gestion et leur archivage. 2.4.1.4 Gestion d'un parc de 3000 ressources

Une installation Tivoli pour gérer 3000 équipements requiert en moyenne 8000 agents. La gure 2.12(b) illustre les principaux composants ainsi que l'architecture globale de déploiement de IBM Tivoli dans tels scénarios. Nous pouvons distinguer dans la gure deux instances Tivoli (chacune de 1500 ressources). Le lien entre les deux instances est assuré par composant d'archivage TDW (entrepôt de données mutualisé) et par le module

de consolidation des évènements TMR/TEC. IBM recommande le partage de ces deux modules dans un contexte très large échelle.

2.4.1.5 Synthèse

IBM Tivoli est l'un des systèmes d'administration les plus complets sur le marché. Nous avons présenté dans cette section une des dernières versions de ce produit. Le produit dispose d'une architecture fonctionnelle modulaire qui distingue bien les composants de traitement de ceux de la présentation et de l'archivage. Concernant le passage à l'échelle, le produit donne le choix à l'administrateur de choisir le modèle de gestion (une gestion centralisé, centralisée hiérarchique et complètement distribuée) qui lui convient le mieux. Nous avons présenté dans cette section ces possibilités de passage à l'échelle à travers deux exemples de 1500 et de 3000 ressources administrées. Néanmoins, les principales limitations de Tivoli sont certainement le coût onéreux de ce produit et la diculté d'extension par les utilisateurs. De point de vue de l'éditeur de la solution, les principales dicultés sont la complexité des API du produit et la diculté de l'administration de l'outil lui-même au cours de l'exécution. De plus, Tivoli, ne propose pas d'outils pour s'administrer lui-même. An d'avoir une vue plus complète sur le marché des outils d'administration, nous présentons dans la section suivante un autre classique des systèmes d'administration.