Mise en place d’une CMDB au CC Emmanouil VAMVAKOPOULOS Sylvain REYNAUD Frédéric AZEVEDO 25/11/2016

Historique 2012 Mars : Expression des Besoins avec échéance souhaitée fin d’année Juin : Début du projet (première réunion de travail) 2013 Janvier : Définition du modèle de données Jusqu’à Juin : évaluations de CMDBuild et iTop 2014 : Mai : renfort humain sur le projet (Sylvain) Début du développement (évolution de Lavoisier puis import dans CMDBuild) 2015 : Janvier : renfort sur le projet (Fabien JOYON) Déploiement de CMDBuild, Lavoisier, import de données Intégration d’éléments de configuration Dcache, xrootd, gpfs, workers, réseau Prototypage d’outils se basant sur la CMDB Analyse d’impact API REST Décembre Service officiellement en pré-production Départ de Fabien J.  transfert de connaissance à Noua TOUKOUROU 2016 Intégration d’autres éléments de configurations Base de données, Openstack Développements d’outils se basant sur la CMDB: Analyse d’impact et Dashboard (Jonathan MOUTARDE) Départ de Noua T.

La mise à jour des données Ce qui est en place Une base de données Eléments de configurations et leurs relations Information sur la configuration de certains services Sources de données : smurf, puppetdb, information de configuration de services, … La mise à jour des données 3 fois par jour (ensemble des données) 1 fois par heure (données concernant le status/realm) L’accès aux données via API REST et GUIs En résumé, tout est là pour Ajouter de nouveaux éléments de configurations Intégrer les informations de configurations de services Utiliser/développer des outils en utilisant l’API REST Une interface web d’analyse d’impact (voir présentation de Sylvain qui suit) http://cccmdb.in2p3.fr:8080/lavoisier/impact

Développements effectués

Retour d'expérience sur et Modèle de données Outils développés Plan CMDB Définition Application au CC-IN2P3 Retour d'expérience sur et Modèle de données Outils développés Conclusion Perspectives Difficultés rencontrées

CMDB = Configuration Management DataBase CMDB : définition de Wikipédia  application au CC-IN2P3 CMDB = Configuration Management DataBase C'est une base de données unifiant les composants d'un système informatique @CC : le système considéré est le centre de calcul de l'IN2P3 Elle permet de comprendre l'organisation entre ceux-ci  OUI @CC : plus de 20 000 relations mises-à-jour automatiquement et de modifier leur configuration  NON @CC : la configuration est modifiée par les experts avec leurs outils Un composant fondamental d'une architecture ITIL

La CMDB contient des informations sur CMDB : définition de Wikipédia  application au CC-IN2P3 La CMDB contient des informations sur les principaux composants du système d'information matériel : routeurs, switch, racks, machines physiques/virtuelles logiciel : instances de service, composants constituant l'instance humains : utilisateurs, experts de services les relations importantes entre eux par exemple, pour une instance de service : quelles machines le font tourner ? quels utilisateurs l'utilisent ? quels autres services en dépendent ?

Pour chaque service, au minimum : CMDB : application au CC-IN2P3 - cas particulier des services Pour chaque service, au minimum : Dépendance sur le matériel Fourni par l'infrastructure (smurf-db, puppet-db, DNS…) Dépendance (macroscopiques) sur d'autres services 164 relations maintenues manuellement pour l'astreinte Pour certains services, interroger/analyser les informations de configuration pour en extraire… Relations avec les groupes d'utilisateurs (+ niveau criticité) Relations entre les composants (+ redondance) Relations avec les autres services (+ niveau criticité) Services ayant ce niveau d'intégration aujourd'hui dCache, XRootD, GPFS, databases, Load Bal., (Grid Engine, OpenStack)

Retour d'expérience sur Interfaces pas adaptées CMDB import postgres

Retour d'expérience sur Impact analysis dashboard REST CMDB import CMDB UI . SOAP Beaucoup trop lent !!! postgres

Retour d'expérience sur Impact analysis dashboard REST CMDB import CMDB UI . REST Langage de requête trop limité postgres

Dépendance sur le fonctionnement Retour d'expérience sur Impact analysis dashboard REST Jointures trop complexes CMDB import CMDB UI . SQL Dépendance sur le fonctionnement interne de l'outil postgres

Retour d'expérience sur Impact analysis dashboard REST CMDB import CMDB UI . Performance: attributs des relations récupérés 1 par 1 Fiabilité: contrôles faits par la GUI sont by-passés via REST Débogage: aucun indice sur la nature et la localisation de l'erreur Problèmes: Performance Fiabilité Débogage postgres

Retour d'expérience sur Impact analysis dashboard REST CMDB import CMDB UI . postgres cache

Retour d'expérience sur Impact analysis dashboard Impact analysis dashboard REST REST CMDB import CMDB UI . CMDB UI . postgres cache

Mais quand même quelques points forts… Open Source SGBDR avec Retour d'expérience sur Mais quand même quelques points forts… Open Source SGBDR avec Gestion de l'historique Plus ou moins transparent… Gestion de l'héritage Permet la spécialisation d'une classe (e.g. matériel, service) Outil dédié aux CMDB, probablement adapté en cas de Modèle simple Saisie manuelle

Base de données Avantages Inconvénients NoSQL Orientée graphe . Base de données NoSQL Orientée graphe Open source Avantages Déploiement très peu contraignant (intégré à Lavoisier) Rapide Flexible (modèle semi-structuré) Langage de requête simple et puissant Inconvénients Ce n'est pas un outil de CMDB Ne gère pas l'historique (contrairement à CMDBuild)

Relations d'impact Compromis entre… …et non de composition (SGBDR) Modèle de données Relations d'impact …et non de composition (SGBDR) Compromis entre… Simplicité (seulement 13 classes) Compatibilité avec l'ensemble des services du CC-IN2P3 Compatibilité avec l'analyse d'impact (graphe acyclique orienté)

Modèle de données Nœud = classe d'objets Flèche = impact

Nœud = classe d'objets Flèche = impact Modèle de données : relations entre les composants (grosse granularité) Nœud = classe d'objets Flèche = impact

Nœud = classe d'objets Flèche = impact Modèle de données : relations entre les composants (granularité fine) Nœud = classe d'objets Flèche = impact

Nœud = classe d'objets Flèche = impact Modèle de données : exemple d'extension du modèle (OPENSTACK) Nœud = classe d'objets Flèche = impact

REST Interfaces utilisateur : REST API CMDB UI . Impact analysis dashboard REST REST CMDB UI .

Input : requête en Cypher (presque du ASCII art !) Interfaces utilisateur : REST API Input : requête en Cypher (presque du ASCII art !) (n:Server)-->(:Configuration {Service:"GE"}) (hv:Server)-->(:Configuration)-->(vm:Server)-[*3]->(:ServiceElement) Output Choix entre 2 opérations /lavoisier/query retourne un tableau /lavoisier/impact retourne la description d'un graphe Choix du format pour chaque opération Tous les formats supportés par Lavoisier (e.g. JSON, XML, CSV…) Server Config GE Server Config Server Service

Interfaces utilisateur : GUI (développées par J. Moutarde) Impact analysis dashboard REST CMDB UI .

Construites au dessus de la REST API Analyse d'impact Interfaces utilisateur : GUI (développées par J. Moutarde) Construites au dessus de la REST API Analyse d'impact Impact en fonction de la redondance et de la criticité calculée Causes possibles communes à plusieurs pannes simultanées Dashboard (en cours…) Choix des widgets et de leur disposition dans la page (layout) Choix des requêtes Choix du rendu Edition de rapports (non commencé) Basé sur Jasper Report (de Jaspersoft Community) Impact analysis dashboard

Interfaces utilisateur : GUI pour l'analyse d'impact DEMO

Interfaces utilisateur : GUI pour dashboard personnalisable

Concernant l'outil d'import des données Perspectives Concernant l'outil d'import des données Améliorer la gestion des incohérences détectées (notifier ?) Remplacer CMDBBuild par une BD (pour l'historique)? Concernant l'intégration des services Suivre l'évolution des services déjà intégrés Nouvelles informations disponibles (e.g. redondance) Informations disponibles autrement (e.g. changement de techno.) Continuer d'intégrer d'autres services Concernant les interfaces graphiques Analyse d'impact : affiner le calcul de la criticité Dashboard : à terminer Edition de rapports : à développer

Interaction avec d'autres outils du CC ? Perspectives Interaction avec d'autres outils du CC ?  nécessité d'un nommage commun des services Astreinte Dépendances Criticités Experts Liens vers fiches astreinte NAGIOS autres ?

A beaucoup évolué au cours du projet… Maintenant Difficultés rencontrées : le modèle de données A beaucoup évolué au cours du projet… Maintenant Stabilisé Eprouvé avec l'intégration de services très différents Peut être étendu pour répondre à des cas particuliers Les hyperviseurs d'OpenStack sont des configurations qui impactent des serveurs (i.e. des machines virtuelles). Les dépendances de dCache n'impactent pas tous les poolgroups de la même façon.

Entièrement développé par assemblage… Difficultés rencontrées : hétérogénéité des techno/formats employés Entièrement développé par assemblage… de templates (règles de transformation du flux de données) de composants logiciels réutilisables pour les protocoles et technologies <connector> pour les formats de données en entrée <serializer> en sortie <renderer> pour la validation des données <validator> pour la mise en cache <cache> pour la sécurité <authenticator> …grâce au framework Lavoisier http://software.in2p3.fr/lavoisier/

Quelle décision en cas d'incohérence détectée? Difficultés restantes Quelle décision en cas d'incohérence détectée? Annuler la mise à jour pour garder la cohérence ? Quel durée de validité des données ? Continuer la mise à jour pour avoir des données fraiches ? Quel niveau de tolérance ? A-t-on des use-cases utilisant l'historique des changements de configuration détectés par la CMDB ? Retours des utilisateurs sont bienvenus Cohérence des données Ergonomie des interfaces proposées Use-cases (requêtes prédéfinies, autres outils, autres données)

Pour conclure sur le projet

Besoins initiaux satisfaits ? « La gestion du cycle de vie des CI » Non : la base centralise les informations contenues dans des outils métiers. Pas de modifications possibles. « la gestion des relations entre CI » Oui « l’historisation des CI et de leurs relations » Oui avec CMDBuild (remplacement par une base de données relationnelle envisagé) « l’évolutivité » « la capacité à faire du reporting » Limité avec CMDBuild Développement d’un plugin Lavoisier prévu à cet effet « l’analyse d'impacts » « l’interfaçage avec des outils tiers dont ceux d'inventaire et de découverte ou de tickets » Partiel (exemple : données RANE présentes mais périmées car pas d’accès directe aux données) « la gestion de processus (workflow) » Non. Pas compatible avec une CMDB en lecture seule. « la gestion des rôles et des habilitations » Non. Pas d’intérêt avec une CMDB en lecture seule.

Des besoins sont satisfaits, d’autres non La suite ? Des besoins sont satisfaits, d’autres non Sont-ils toujours d’actualité ? Y en a-t-il de nouveaux ? Projet de « mise en place d’une CMDB au CC » Prêt d’un point de vu technique : utilisable, mais à compléter A finaliser sur l’aspect documentaire et formation Reste également à définir Qui valide les données ? Comment sont gérés les changements ? Ajout, retrait, modification d’éléments de configurations Qui est responsable de ce nouveau service ? Assurer la maintenance, l’évolution et l’amélioration continue Qui l’exploite ? Faire en sorte que le système fonctionne et fournisse le service attendu. A continuer sous quelle forme ? un nouveau projet ? une activité ?