Académique Documents
Professionnel Documents
Culture Documents
Virgile Gerecke
Direction Informatique
14 rue Ren Descartes
67 000 Strasbourg
Julien Dupr
Direction Informatique
14 rue Ren Descartes
67 000 Strasbourg
Rsum
La CMDB, ou base de donnes de gestion des configurations, est au cur du processus de gestion des confi-
gurations. Cest un des premiers et des rares outils mis en avant par ITIL. Plus quun inventaire, la CMDB
est cense faire le lien entre diffrents lments issus de multiples inventaires et rfrentiels et apporter une
version historise de ces lments et de leurs relations. Pour autant, cest un outil qui, sil semble promet-
teur au sortir dune formation ITIL, est surtout trs thorique et difficile implmenter. En 2009 un premier
groupe de travail de la Direction Informatique de lUniversit de Strasbourg avait dailleurs planch sur le
sujet de la CMDB sans aboutir une implmentation possible, fut-t-elle parcellaire. Enfin, la plus-value par
rapport un outil dinventaire classique nest pas vidente au premier abord mais se rvle incontournable
lusage.
Sappuyant sur les dmarches qualit entreprises depuis 2009, la Direction Informatique de lUniversit de
Strasbourg a lanc depuis 2013 un projet de mise en oeuvre dune CMDB portant sur un vaste primtre.
Un catalogue dune centaine de services offerts est finalement li plus de 300 applications, 200 serveurs
physiques, 1800 quipements rseaux, 200 lieux, 300 "clients" et contacts, 400 organisations et structures.
Les donnes voques reprsentent plus de 13 000 objets qui auront t injects dans la CMDB. La rali-
sation de la CMDB sappuie sur iTop, un produit dont les qualits et les limites seront exposes lors de la
prsentation. Nous nous attacherons particulirement dmontrer la souplesse de loutil et sa capacit
sinterfacer avec de nombreux lments dun systme dinformation de faon efficace.
Mots clefs
ITIL, CMDB, ITOP, Gestion des configurations, inventaire, donnes de rfrence, ETL
1 Introduction
1.1 Contexte
Ds 2009, le concept de CMDB avait fait quelques mules et semblait tre un Graal atteindre. La CMDB
(Configuration Management DataBase) doit rfrencer toutes les informations utiles lexploitation des
services informatiques. Les lments composant la CMDB sont appels CI ou "Configuration Items". Il
peut sagir de services, dapplications, de serveurs ou dquipements rseaux, de postes de travail, de do-
cumentations de contrats ou de procdures. La CMDB est donc cense rfrencer ces lments et les lier
entre eux. Elle doit galement historiser les informations et cest (outre son primtre trs large) ce qui la
distingue dun inventaire classique. Ds 2009, un premier groupe pilote avait planch sur la mise en place
de cet outil merveilleux, sans aboutir. Le manque doutils disponibles, lampleur de la tche avait finalement
dcourag les plus enthousiastes.
En 2012, un peu de veille technologique et la comparaison de divers outils libres (oneCMDB, iTop) ont
finalement conduit la mise en place dune maquette diTop un outil qui avait t prsent aux RMLLs
Strasbourg. iTop est un logiciel libre, dvelopp principalement par la socit Combodo qui se prsente
comme un outil ITSM et CMDB. Au-del de la CMDB, la promesse diTop est donc daider la gestion des
services informatiques. Des processus intgrs loutil comme la gestion des changements ou la gestion
des incidents (systme de tickets) doivent donc apporter un plus, comme si la seule CMDB ne suffisait pas
aux ambitions des dveloppeurs. On peut aussi considrer quil sagit au final dutiliser les lments de la
CMDB afin de faciliter le travail quotidien. iTop est dvelopp en PHP et est accessible via une interface
web. Il possde deux qualits principales :
des mcanismes dimport et de synchronisation qui feront lobjet de la premire partie de cet article ;
un modle de donne extensible qui sera prsent dans une seconde partie.
Malgr ces qualits, la maquette iTop a rapidement pris la poussire courant 2013. Personne ne semblait
finalement sy intresser. En 2014, ltude a t ractive car de nouveaux besoins ont merg qui pouvaient
tre satisfaits par la maquette. Ces moments sont instructifs et nous tudierons dans cet article loutil plus
en dtail afin den prsenter les qualits et les limites, les difficults se lapproprier. Cela fera lobjet dune
troisime partie qui sera galement loccasion de prsenter les apports inattendus de la dmarche.
2 Synchronisations et imports
Une fois les premiers tests manuels effectus, vient rapidement la tentation dinsrer des donnes relles
dans la CMDB naissante. Le produit permet des imports CSV et propose des tables de synchronisation.
On pioche, on agrge, on lie les lments entre eux plus ou moins proprement. On obtient rapidement
une plateforme de dmonstration permettant dvaluer le potentiel de la dmarche. Mais tout se complique
lorsquil sagit de mettre en place les lments ncessaires une mise en oeuvre effective et au maintien de
la pertinence des donnes. Voici donc les tapes suivies lUniversit de Strasbourg.
La premire tape dintgration des donnes est lidentification des sources. Nous avons donc procd un
"inventaire des inventaires" notre disposition. Nous avons donc retenu :
les inventaires dinfrastructure (GLPI) ;
les listes des services et des applications (notre wiki) ;
les contacts, organisations (dans le rfrentiel des personnes et des structures) ;
les btiments (base mtier rfrentiel immobilier) ;
les fonctions (base mtier RH et application de gestion des correspondants) ;
les contacts et utilisateurs (annuaire LDAP) ;
le primtre dintervention de la direction (fichier tableur) ;
linventaire des onduleurs et des climatisations (fichier tableur) ;
les listes des salles gres avec les informations rcoltes par la DI au fur et mesure des annes
(fichier tableur).
Avec laide des experts des diffrents domaines couverts par la CMDB, nous avons ralis un tableau
rcapitulatif de lensemble de ces donnes comprenant la description de la source, les champs intgrer et
les rgles dusage (par exemple les rgles concernant les statuts des objets).
Cette tape a permis dobtenir une vision globale sur les donnes utiliser. Mais elle a aussi t loccasion
de procder lanalyse de notre capacit matriser nos donnes dans le temps. En effet, bien avant la
CMDB, des liens existaient entre les donnes de certaines bases. Malheureusement, ces liens pouvaient
souffrir dobsolescence dune part cause du type de lien et dautre part cause des donnes elles-mmes.
Lexemple le plus flagrant tait le lien entre les lieux et les quipements. Dun ct, les lieux avaient t
imports une fois dans loutil dinventaire dinfrastructure sans synchronisation ultrieure. En consquence,
la cration ou la modification de salles entranait la perte de cohrence. De lautre ct, le rfrentiel des
lieux montrait des dcalages entre les donnes saisies et lvolution de la finalit des salles. Typiquement,
des salles contenant des matriels comme des postes pdagogiques et qui taient donc des salles de TP
informatique pouvaient tre rfrences dans linventaire des lieux comme des salles de runion ou des
locaux techniques. Le travail sur la CMDB a permis de mettre en lumire ces deux aspects et de les corriger.
Ce travail fastidieux effectu, les donnes ont pu tre intgres dans iTop tout en nous rappelant limportance
des contrles de cohrence des donnes dans le cycle de vie des objets.
Nous avons donc utilis un produit interne appel synchronisator. Cet outil gnrique permet de rcuprer
des donnes dans une source spcifie laide de services web ou de requtes SQL. Nous exploitons donc
les possibilits daccs aux donnes de nos inventaires et dfaut, nous avons construit une bibliothque de
requtes SQL.
Les donnes sont ensuite transformes pour correspondre dune part aux rgles dusage dfinies lors de
lidentification des sources mais aussi pour consolider les liens entre les lments dinventaire. En effet,
iTop utilise un systme dhritage pour les lments de configuration. Cela permet de partager des pro-
prits communes entre les classes dobjet. Nous avons ainsi dfini un identifiant extrieur permettant de
rconcilier les donnes lors des synchronisations. Il faut donc sassurer de lunicit des identifiants externes
des objets pour viter les problmes dambigut sur les liens. Car si iTop permet deux lments davoir
un mme identifiant externe, il provoque une erreur dimport en cas dincertitude. Parmi les transforma-
tions de donnes, synchronisator applique des rgles de construction didentifiant unique en prfixant les
identifiants externes.
Dans certains cas le modle diTop nous impose lutilisation de classes dobjet. Ainsi, nos sondes dinven-
taire ne remontent pas de donnes concernant les hyperviseurs. Comme cette information sera peut-tre
utilise dans le futur, nous navons pas souhait altrer le modle de donnes et nous devons donc crer des
objets virtuels hyperviseurs afin de lier entre eux serveurs et machines virtuelles. Synchronisator permet de
crer les lments virtuels qui ne remontent pas automatiquement dans linventaire. Dans notre cas, il
sagit par exemple des hyperviseurs. iTop dfinit les machines virtuelles comme on le voit sur la figure 1 :
Machine
virtuelle
Hyperviseur
Serveur
Lintgration des donnes se droule en deux temps. Tout dabord il faut remplir les tables de synchroni-
sation diTop avec les donnes prpares. Dans notre cas, cest une nouvelle fois synchronisator qui sen
charge mais dautres scripts maisons peuvent faire laffaire. Ensuite, les possibilits dintgration et la flexi-
bilit diTop entrent en oeuvre. En effet, lors de la dfinition dune synchronisation, une table est cre avec
tous les champs dune classe iTop. Pour chacun de ces champs, on peut dfinir comme on le voit sur la
figure 2 :
si le champ participe la rconciliation des donnes, avec la possibilit de rconcilier sur plusieurs
champs ;
si le champ doit tre mis jour ;
la politique concernant la mise jour des donnes (crasement ou alimentation si vide) ;
si le champ peut-tre mis jour manuellement ;
la cl de recherche pour les objets lis (par exemple le nom de lorganisation dont dpend un lment
de configuration, ce quon qualifie de jointure en SQL).
Une fois les donnes prsentes dans ces tables de synchronisation, iTop se charge de ventiler les infor-
mations dans son propre schma de base de donnes. Ce mode de fonctionnement permet de conserver
lhistorique des modifications et de sabstraire des subtilits du modle de donnes, rendu complexe par
le systme dhritage entre objets. Il permet aussi dassurer la prennit des synchronisations. Il faut noter
quune attention particulire doit tre porte aux cls externes permettant la rconciliation des donnes.
Nous avons d mettre en place, malheureusement aprs lapparition de conflits, une nomenclature permet-
tant dexclure tout recouvrement sur ces cls externes.
Lensemble des lments ncessaires la remonte automatique des informations depuis nos diffrents
inventaires a ncessit environ un mois-homme.
La dmarche de mise en place dune CMDB a aussi t loccasion de rfrencer toutes les donnes, lments
de configuration ou liens entre lments, stockes hors base de donnes norme. Il sagissait essentiellement
de fichiers tableurs mis en place en labsence doutil adquat ou abordable pour la gestion de ces donnes.
Les informations pouvaient tre fragmentes (il existait plusieurs fichiers de gestion de salles) et les donnes
constitutives ntaient que faiblement lies au S.I. Nous avons essay dautomatiser le plus de rapproche-
ments possibles pour les donnes simples, en essayant dinterprter les informations saisies comme le nom
des contacts, tout en grant les ventuelles fautes de frappes ou les diffrences de format. Pour le reste, un
fastidieux travail manuel a t men afin de rconcilier les lments textuels avec les donnes du S.I. et
ainsi exploiter la somme de connaissances accumules dans ces fichiers.
Les scripts de rapprochement des donnes ont t raliss en deux jours-homme. Le rapprochement manuel
a reprsent prs dune semaine-homme juste pour la rcupration du fichier tableur lies aux donnes
descalade. Toutes ces donnes ont ensuite t intgres au format CSV dans iTop, grce un module ddi
ce type dopration.
Notre CMDB agrge, intgre et lie les lments de configuration provenant de sources diverses. Nous
avons vu au paragraphe 2.3 quiTop servait galement de source de donnes. En effet, les informations sont
directement saisies et gres dans loutil dans le cas dobjets pour lesquels il nexiste pas de rfrentiel (ou
pas de rfrentiel satisfaisant). Cest le cas de notre catalogue des services par exemple.
Toutefois, iTop permet aussi denrichir les donnes dobjets provenant de nos inventaires avec par exemple
lajout de commentaires techniques propres nos usages et qui nauraient pas dintrt pour les utilisateurs
initiaux. Ainsi on voit sur la figure 3 que le champ description que nous avons ajout nest pas verrouill :
2.4.2 Suppression
Une fois quun objet est cr, il est li dautres et peut mme tre enrichi. Sil provient dune source
externe, il a fait lobjet dune synchronisation et des restrictions peuvent sappliquer sur les manipulations
dont il peut faire lobjet. Ainsi, certains champs aliments automatiquement peuvent tre verrouills. Cest
pourquoi iTop ne permet pas de suppression partir de synchronisation. Cela vite les suppressions non
dsires (lors dune synchronisation qui choue par exemple) et force adopter une stratgie spcifique.
Tous les objets que nous manipulons ont donc t pourvus dun statut qui permet de grer le cycle de vie.
Ainsi, un serveur peut tre en stock, puis avoir un usage dfini et enfin tre retir. Il reste quand mme
prsent dans la CMDB. Avant toute suppression, une analyse de la situation est mene afin de sassurer que
tous les liens vers ce serveur ont bien t mis jour dans la ralit et dans loutil. Une fois ces vrifications
ncessaires effectues, il peut tre supprim en toute scurit des synchronisations et des objets grs. Cela
permet la fois de limiter les risques de perte dinformation ct CMDB mais aussi et surtout dexploiter
ces donnes afin dliminer tout effet de bord indsirable au retrait de lobjet.
Il est tonnant de constater que si iTop propose des statuts prts lemploi pour plusieurs lments de
configuration (comme les serveurs), tous les objets ne peuvent tre inactivs nativement (instances de base
de donnes ou utilisateurs LDAP par exemple). Nous avons compens ces manques par lajout des champs
correspondants.
3 Modle de donnes
Le modle de donnes est llment central de la gestion des configurations. iTop propose un modle par
dfaut riche et proche de nombreux usages. Nous avons vu quil tait ncessaire de faire voluer ce modle
car la CMDB est aussi source de donnes (cf. 2.4.1) et bien souvent des informations qui sont importantes
dans notre contexte dutilisation ne sont pas prsentes dans loutil par dfaut.
Par exemple, pour notre catalogue de services, nous avons d ajouter des champs qui ntaient pas prsents
dans iTop comme la criticit du service, le fait quil soit ou non utilis par certaines populations (tudiants,
enseignants/chercheurs, personnels administratifs et techniques, etc.) ou le fait que certains services soient
internes la DSI.
Par ailleurs, toujours concernant la modlisation des services, nous aurions pu reproduire la structure exis-
tante ralise partir de notre wiki (figure 4).
Mais cette reprsentation ne refltait ni la diversit de nos clients, ni les diffrents environnements mis en
uvre. Nous avons donc opt pour une modlisation plus ambitieuse et plus proche de la ralit (figure 5)
qui permet dexploiter au mieux les fonctionnalits dtude dimpact et de dpendance de loutil (voir 4.5) :
Le modle diTop est fait pour tre tendu. Tous les objets sont dcrits sous forme de classes qui bnficient
dun systme dhritage. Il est donc ais de crer de nouvelles classes, de modifier des classes existantes ou
dtendre des classes.
Application Application
Acolad Moodle
Service
Plate forme pdagogique
Lensemble de ces classes est dcrit sous forme de fichiers XML de configuration comprenant :
des donnes de configuration de stockage ;
la liste des champs et de leurs donnes jointes (la plupart des lments est lie une organisation dont
on stocke lidentifiant org_id mais dont on affiche simplement le nom grce une jointure implicite
offerte par iTop) ;
la configuration de laffichage des donnes de la classe ;
la configuration des formulaires de recherche dobjets.
iTop propose de nombreuses classes dans son modle par dfaut. Afin de prserver les possibilits de mise
jour, toutes les modifications du modle passent par un systme de modules. Nous pouvons donc crer des
modules spcifiques chaque but vis, comprenant une conjonction de classes modifies et/ou nouvelles.
La mise en place dune CMDB a cr de nombreuses attentes, portant sur diverses problmatiques. Nous
avons donc cr des modules pour :
les fluides (onduleurs, alimentations, climatisations qui sont des notions absentes diTop) ;
les salles (extension des lieux pour permettre dapporter de nombreuses prcisions) ;
de nombreux liens avec des contacts (nos correspondants au sein des structures clients, des respon-
sables administratifs ou de filire, etc.) ;
larchitecture de nos applications comme dcrite au paragraphe 3.1 ;
les flux de donnes entre les diffrents lments du S.I.
etc.
La dmarche autour de la CMDB a rellement dmarr dbut 2013 avec une premire maquette diTop.
Pourtant, un rel projet na pu voir le jour que mi-2014. On peut sinterroger sur ce dcalage. Si la CMDB
tait le Graal comment se fait-t-il que son implmentation ait mis autant de temps prendre racine ? On
pourrait avec facilit voquer une charge de travail consquente qui ne laissait que peu de place aux expri-
mentations mais on peut galement aller plus loin dans lanalyse. Dans un premier temps, une CMDB mme
adosse un ronflant volet de gestion de services (ITSM - IT Service Management) semble simplement tre
un outil de plus, encore un outil, qui napporte pas de relle plus-value :
des outils dinventaires au niveau du parc ou des lments dinfrastructure sont dj en place ;
les applications et les services ont probablement dj t cartographis par des architectes du systme
dinformation ou des qualiticiens ;
la prsence trs probable dun outil de gestion de ticket interne qui donne satisfaction dans les grandes
lignes semblent rendre caduc le volet ITSM diTop.
Considrant le cot de mise en place dune maquette avec des donnes relles, la mise en place de la CMDB
ressemble un luxe que lon ne peut pas se permettre.
Le facteur qui a permis la dmarche davancer lUniversit de Strasbourg a t la volont du responsable
du support informatique de structurer et de lier de nombreuses donnes concernant le primtre dinter-
vention de la DI. Ce primtre dune complexit extrme qui tait pralablement dcrit dans un tableur
impossible maintenir a servi de catalyseur pour le projet de mise en place de la CMDB dans la mesure
o il fallait lier les services, les clients, les btiments et les quipements. Dune manire ou dune autre,
la prsence dun besoin non satisfait sert de mouche du coche pour ce genre de dmarche. Par ailleurs, le
fait de se focaliser sur ce besoin particulier peut permettre dviter de se disperser, ce qui est important
dans le cas de la CMDB. Le projet men Strasbourg est parfois tomb dans le pige de la multiplicit des
cibles vises. Cette dispersion provoque un effet secondaire viter dans le sens o cela peut allonger les
dlais de ralisation. La prsence de mcanismes de synchronisation de donnes voqus dans le chapitre 2
a galement facilit la ralisation dune maquette convaincante, cest--dire prsentant des donnes relles.
Une CMDB propose une agrgation de donnes existantes dans le systme dinformation, mais permet aussi
la saisie dlments manquants. Cette situation provoque 2 types de problmes diffrents :
dans le cas dlments existants, il sagit de les rcuprer dans des bases sources diverses. Cette ma-
nuvre peut engendrer des effets de bord : certaines donnes qui taient prsentes dans ces bases
sources peuvent tre compltes par des donnes saisies manuellement. Il peut savrer pertinent de
dcaler cette saisie manuelle pour quelle se fasse dsormais dans la CMDB, mais cela implique de
changer des pratiques. Dans ce cas prcis, il faut mettre en avant un gain, faute de quoi ce change-
ment naura pas lieu. Il faut alors trouver des rponses aux questions suivantes : que peut apporter
- directement - la CMDB ceux qui doivent alors changer leurs pratiques ? Quels gains pour tous
les collgues ? La rponse ces questions ne peut se trouver quen travaillant directement avec les
4.5 Bonus
Nous allons voquer dans ce chapitre deux bnfices induits par la dmarche et qui mritent dtre souligns.
Le premier a dj t voqu, il sagit du dcloisonnement de linformation et du lien entre des informations
qui taient isoles. Des fichiers bureautiques "confidentiels" ou des bases de donnes utilises exclusivement
par une quipe se retrouvent exposs et tous peuvent les consulter. Mme si les corrlations que lon souhaite
alors naturellement raliser ncessitent un travail sur la qualit et la cohrence des donnes, ce point est en
dfinitive bnfique.
Le deuxime point na pas encore t soulign et il mrite de ltre : iTop prsente une fonctionnalit
intressante danalyse dimpact. Pour un lment de configuration (CI) donn on peut valuer (en fonction
de son type) :
de quoi il dpend ;
ce quil impacte.
On peut ainsi essayer de dterminer limpact dune maintenance ou dune panne ce qui donnera la rponse
la question magique "que se passe-t-il si je casse ceci ?". iTop ne donne pas dattribut aux liens de d-
pendances, on ne peut donc pas modliser finement une architecture impliquant de la redondance. Cela
veut dire que lanalyse dimpact ne dterminera pas automatiquement leffet dune indisponibilit dun CI.
Lanalyse dun ingnieur matrisant larchitecture reste ncessaire, mais cest probablement mieux ainsi.
Lanalyse dimpact permet dattirer lattention sur un impact potentiel, que ce dernier soit matris par une
architecture redondante ou pas.
5 Conclusion
On le voit dans cet article, la mise en place dune CMDB nest pas un Graal inaccessible. Toutefois, le projet
de mise en place dun tel outil nest pas trivial et il a des impacts multiples et ncessite une forte intgration
au systme dinformation. Justement, quand la route est longue, et dans la mesure o la CMDB prsente
de nombreuses facettes, il convient de se focaliser sur des objectifs ralistes et davancer par tapes, de
dcouper le SI en morceaux afin de prsenter des rsultats intermdiaires qui permettent de dmontrer les
apports de la dmarche.