Archive

Posts Tagged ‘cmdb’

iTop 2, donnez un coup de carte à votre SI

November 3rd, 2012 2 comments

Depuis quelques jours, une version alpha d’iTop 2 est disponible chez mes amis de Combodo. iTop est un fabuleux outil qui vous permet de créer votre propre CMDB, et d’y associer des services tels que la gestion de tickets (incidents, changements). Pour rappel, une CMDB (Configuration Management DataBase) décrit l’ensemble des composants d’un système d’information. Cela peut aller du SAN, serveur physique, machine virtuelle, carte réseaux, switch jusqu’a remonter à la couche applicative : serveur d’application (par exemple Tomcat), application, etc.

L’objectif d’une telle base de données est de pouvoir d’une part cartographier votre SI, mais surtout de pouvoir faire des liens entre tous ces objets, ce qui permet d’en obtenir des analyses de dépendances (de quelle brique technique mon application métier a besoin pour fonctionner) et aussi des analyses d’impact (il se passe quoi si j’éteins ce serveur).

Les nouveautés visibles d’iTop 2

Rentrons dans le vif du sujet, à savoir quelles sont les nouveautés – point de vue utilisateur – de cette nouvelle version ? Et bien, la réponse courte tiens en deux mots : “le modèle”. Concrètement, si vous êtes utilisateur ou même testeur de la première version, vous aviez remarquez l’absence des machines virtuelles dans le modèle de base, ce qui est de nos jours est d’utilisation très courante. Ce manque à – je pense – freiné un peu l’adoption du logiciel.

Donc, voici en vrac les changements notables du modèle (liste non exhaustive) :

  • Machines virtuelles : une VM peut être rattachée – via la notion d’hyperviseur – soit à un serveur physique (zone Solaris, dom0 Xen), soit à un cluster
  • Gestion du SAN, de la baie de stockage aux volumes logiques, en passant par les switch
  • Des attributs supplémentaires tels que la gestion de l’alimentation des serveurs physiques, la gestion des racks/chassis

Un autre changement notable concerne l’installation. Un assistant (wizard) plus complet permet de choisir entre – par exemple – plusieurs niveaux de gestions des tickets.

Les autres nouveautés

L’autre, sinon LA nouveauté d’iTop, bien qu’elle est soit invisible pour les utilisateurs réside dans le changement du format de données décrivant le modèle. Dans la version 1, le modèle est décrit via des fichiers PHP, quelques connaissances de programmation sont donc nécessaire, et surtout il n’était pas facile de maintenir un suivi avec les mises à jour coté iTop.

Dans cette version, les développeurs ont choisi d’utiliser XML, ce qui permettra à chacun de modifier le modèle de données sans avoir à modifier les fichiers fournis par iTop ! Et j’avoue que ça, c’est un point non négligeable pour un intégrateur comme moi ! De plus, l’utilisation de fichiers XML rend plus facilement possible la création d’un éditeur graphique du modèle (qui existe pour les partenaires de Combodo).

Conclusion

Cette nouvelle version est doublement appréciable. D’une part, le modèle est maintenant complet et ne nécessitera que quelques retouches (je pense surtout à l’ajout d’attributs) pour être utilisable dans 90% des cas, et d’autre part, le changement en profondeur du format de description du modèle va considérablement simplifier la vie, et permettra – je l’espère rapidement – la création d’outils pour gérer son modèle.

Categories: Business tools, Sysadmin Tags: ,

Un SI propre avec iTop, RunDeck, Puppet, FusionInventory

March 23rd, 2011 19 comments

Au vu de mes futures (nouvelles ) activités, et parce qu’au XXI ème siècle, on se doit d’avoir un système d’information propre, j’ai commencé une maquette en n’utilisant que des outils libres. Les objectifs sont multiples :

  • l’information ne doit être déclarée qu’à un seul endroit
  • la configuration des serveurs doit être automatisée
  • disposer d’une CMDB
  • automatisé toutes les tâches possibles

Une CMDB, cékoidonc ?

Avant de rentrer dans la technique, je me permet un petit rappel sur la définition d’une CMDB (Configuration Management DataBase), qui est un concept né et normalisé par ITIL. Comme le décrit Wikipedia, une CMDB recense les composants d’un système d’information. Par exemple, la liste des serveurs, mais aussi et surtout la liste des serveurs d’applications, des applications, et de tout autre composant structurant. Une fois renseigné ces différentes briques, il est possible de les regrouper, notamment par solutions applications et par processus métier, et surtout, de lier toutes ces briques. L’objectif ? Définir des relations de dépendance, entre le métier (par exemple “Vendre des articles via mon site d’ecommerce”) et les briques techniques (le serveur “LDAP”). D’une part, renseigner ces informations oblige à documenter ces interactions, et éviter qu’elles ne soient que dans la tête de l’administrateur, mais pour un administrateur, cela permet de répondre à la question fatidique “qu’est ce qui se passe si je change mon serveur LDAP”. Bon nombre d’administrateur vont me dire “mais je sais très bien quelles applications utilisent le LDAP” ou bien encore “c’est dans Puppet, donc j’ai pas à m’en occuper”, je leur répondrais alors “oui, toi tu es conscient de l’impact technique. Si je demande à ta direction s’ils mesurent les impacts business de ta migration, ils vont en penser quoi ?” (Et là, je viens de me faire des ennemis, mais c’est une autre histoire).

Jusqu’il y a encore quelques années, je n’avais trouvé aucun logiciel opensource me permettant de créer cette CMDB. En effet, la plupart des logiciels de ce genre viennent avec un modèle déjà tout prêt. Cependant, nous n’avons pas tous les même besoin, et j’irais presque jusqu’à dire pas tous la même manière de les représenter (même si justement ITIL décrit un modèle de référence). Or, il y a quelques mois de cela, j’ai découvert un nouveau logiciel dans ce monde très spécifique, à savoir iTop. C’est un outil GPL, écrit en PHP, et d’origine française. Ses auteurs sont des anciens de HP, pour qui ils ont déjà travaillés sur ces problématiques. Résultat, bien qu’encore jeune, iTop est un outil formidable, car très simple d’utilisation, mais aussi par sa richesse. En effet, il est relativement aisé de modifier le modèle par défaut (au hasard celui d’ITIL) pour l’adapter à ses besoins. Pour citer un des fondateurs de la société Combodo éditrice de ce logiciel, il est tout à fait possible de schématiser une école maternelle avec ses élèves, ses professeurs, ses salles, etc. C’est typiquement le genre de logiciel que j’affectionne, il répond à un besoin, mais via une approche framework que logiciel rigide.

Exemple d’un processus métier

Voici un exemple du processus métier gérer la configuration. Étant administrateur système mon métier reste technique, chez d’autres sociétés, “Gérer la configuration” sera plutôt une solution applicative qu’un processus métier.

iTop : processus métier

La gestion des jobs

Dans un SI, avec plein de serveurs, il peut être intéressant de pouvoir exécuter des jobs, aussi bien à intervalle régulier, que de manière occasionnelle. Bien entendu, chaque UNIX vient avec un daemon CRON, mais celui-ci est mono serveur, à une syntaxe différente entre les différents UNIX, etc. On pourrait très bien imaginer de gérer les fichiers cron via le logiciel de conformité de configuration, mais cela ne répond qu’au besoin de jobs réguliers. Pour cette brique, je me suis tourné vers RunDeck. Cet outil est un job scheduler en Java, encore une fois un projet relativement jeune, mais qui profite d’une grande expérience puisqu’il est issu des même développeurs que ControlTier, autre outil de job scheduling. Avec quelques lignes de développement PHP, RunDeck utilise iTop pour obtenir la liste des nodes (serveurs), et utilise une notion de tags dans iTop, pour rajouter par exemple le tag puppet que je défini sur les serveurs où l’agent est installé.

La conformité de la configuration

Chers lecteurs, étant donné que vous êtes en grande majorité des administrateurs systèmes, je vais passer outre la description de Puppet. Pour les autres, en quelques mots, c’est un outil qui permet de s’assurer que des classes de serveurs soient configurés de la même manière, par exemple en forçant la présence de tel ou tel package, que le fichier /etc/sshd/sshd_config soit identique, et ce à partir d’un fichier maître, etc. Par défaut, un daemon est présent sur chaque nœud, mais pour ma part j’ai choisi de ne pas l’utiliser, et d’exécuter l’agent via un job RunDeck (avec mon fameux tag). Cela me permet de centraliser via la WebUI de RunDeck la sortie des différentes instances des agents, et également de pouvoir exécuter l’agent avant d’attendre le prochain scheduling

La gestion de l’inventaire

Jusqu’ici, j’ai déclaré mes serveurs (grosso modo nom, adresse IP, informations SSH) dans iTop, mais j’aimerais bien avoir un inventaire plus précis, comme par exemple la liste des packages installés, la quantité de mémoire, etc. Ça tombe bien, il existe un outil performant pour faire l’inventaire d’une machine UNIX, à savoir FusionInventory. Et vous allez me demander, comment intégrer tout ça ? (en fait, je me doute que vous l’aurez déjà deviné). Tout simplement en forçant la présence du paquetage via Puppet, et l’exécution d’un inventaire toujours via Puppet (j’aurais pu également le faire via RunDeck cependant). Ensuite, je collecte le XML que génère FusionInventory, je lui applique quelques XSL, et j’intègre le résultat dans iTop, et tout ça de manière automatique. Voila, la boucle est bouclée.

Pour résumer

Les liens entre les composants

Et demain ?

Et bien, demain, je vais coupler de manière plus forte iTop et puppet. Avec un peu de travail, mais rien de bien compliqué, je vais pouvoir faire en sorte que iTop soit l’origine d’une partie de la configuration, notamment celle métier. L’objectif est par exemple, via iTop, de créer une nouvelle instance Tomcat sur un serveur, et que puppet assure son installation (je le fais déjà, mais via les fichiers de configuration puppet).