Connecter son DCIM à sa CMDB (ServiceNow, Jira, BMC...)

Pourquoi connecter son DCIM à sa CMDB ?

‍

L'intégration bidirectionnelle entre un DCIM (couche physique) et une CMDB type ServiceNow, Jira ou BMC (couche logique/ITSM) permet de :

‍

• Garantir une Source de Vérité unique : L'installation physique d'un serveur dans le DCIM met à jour automatiquement le CI (Configuration Item) dans l'ITSM.
• Éradiquer les serveurs fantômes (zombies) : Croiser l'inventaire logique avec la consommation électrique réelle mesurée dans les baies.
• Fiabiliser le change management : Interdire le décommissionnement matériel sans validation préalable du workflow ITSM.
• Automatiser l'analyse d'impact : Lier une panne électrique (PDU/Onduleur) aux applications métier impactées en temps réel.

Le résultat : Une cartographie complète de bout en bout, de la prise électrique jusqu'au service utilisateur.

‍

‍

L'interconnexion entre votre DCIM (qui représente la réalité physique) et votre CMDB (qui cartographie la logique de service) est aujourd'hui le meilleur moyen d'obtenir une source unique de vérité (SSoT) fiable.

‍

Ensemble, faisons le point sur les enjeux, l'architecture et les étapes de cette intégration devenue indispensable. (Nous avions déjà détaillé les liens entre le DCIM et l'Asset Management, notamment pour comprendre comment ils viennent enrichir votre CMDB).

‍

1. Les bénéfices de la synchronisation DCIM et CMDB

Le fossé historique entre l'IT et le facility management génère des coûts cachés et de sérieux risques d'exploitation. Réconcilier ces deux mondes résout trois problèmes majeurs :

‍

• L’asset fantôme et l'énergie perdue : On estime qu'environ 15 à 25 % des serveurs en datacenter sont des « zombies ». Ils sont allumés et consomment de l'énergie, mais ne font tourner aucune charge utile. Sans lien entre le DCIM et la CMDB, vous payez de l'électricité et de la maintenance pour du vide.
• Le data drift (dérive des données) : Dès qu'un technicien déplace un câble ou un serveur sans mettre à jour manuellement la CMDB, votre base documentaire devient obsolète. Une remontée automatique du terrain via le DCIM garantit l'intégrité de vos données.
• Le mur énergétique : Avec l'arrivée de l'IA et de la (très) haute densité, la marge d'erreur sur la puissance disponible s'est réduite à néant. Il est crucial de savoir en temps réel si un rack peut supporter un nouveau serveur d'un point de vue électrique et thermique, avant même de passer commande.

‍

2. Fédération de données : Répartition des rôles Master/Slave

Plutôt que de chercher à définir un outil maître et un outil esclave absolu, l'architecture moderne repose sur la fédération de données. Chaque système reste la référence (Master) sur son domaine d'expertise, et s'enrichit mutuellement grâce à une synchronisation bidirectionnelle.

‍

‍

Cette ségrégation stricte garantit qu'aucune donnée n'est écrasée par erreur : si la CMDB passe un serveur en « maintenance planifiée », le DCIM le sait et cesse d'alerter si la consommation électrique de ce serveur chute brutalement.

‍

3. Le cycle de vie automatisé (Automated Lifecycle Management)

Connecter vos outils permet de transformer des processus manuels en workflows zéro erreur. Voici un exemple de scénario de provisioning piloté par API :

‍

1. Demande : L'utilisateur demande le déploiement d'un nouveau cluster physique via BMC ou ServiceNow.
2. Simulation : La CMDB interroge le DCIM via API pour trouver où placer 5 serveurs de 700W avec une redondance complète.
3. Réservation : Le DCIM identifie les racks optimaux en croisant le poids, le froid et l'électricité disponibles, et en réserve l'espace en U.
4. Installation physique : Le technicien installe le matériel et valide l'emplacement exact en scannant l'Asset Tag via une application liée au DCIM.
5. Validation et Webhook : La détection de la nouvelle consommation sur les PDUs intelligents vient comme une validation secondaire confirmant que l'équipement est bien alimenté (voir notre article dédié aux PDU). Le DCIM envoie alors instantanément un Webhook à la CMDB pour déclencher la mise en production.

Exemple de payload Webhook généré par le DCIM vers l'API ServiceNow :

‍

{
  "event": "asset_installation_confirmed",
  "device": {
    "hostname": "HPE-DL380-SRV01",
    "serial_number": "CZJ834591",
    "location": "Site-Paris-1, Rack-A12, U14-U15",
    "power_draw_w": 340
  },
  "cmdb_action": "update_ci_status",
  "target_status": "in_production"
}

‍

4. Analyse d'impact : Fusion des topologies logiques et physiques

C’est ici que la valeur métier se perçoit le mieux. En fusionnant les graphes physiques et logiques, vous obtenez une cartographie complète de vos dépendances.

‍

• Propagation de panne : Si une source électrique (TGBT) tombe, le système croise les données de câblage du DCIM avec les clusters applicatifs de la CMDB. Vous savez instantanément quel service métier (ex: le CRM) tourne en mode dégradé.
• Détection des SPOF (Single Point of Failure) : Le système alerte automatiquement si deux nœuds de calcul d'un même cluster de haute disponibilité sont branchés physiquement sur le même switch ToR ou le même PDU.

‍

5. Reporting RSE et facturation énergétique granulaire

Avec les nouvelles directives environnementales (comme la directive CSRD en Europe), le reporting énergétique ne peut plus se contenter d'estimations.

‍

• Empreinte carbone réelle : Le DCIM remonte la consommation IT exacte de chaque équipement. En appliquant le PUE global du site, il devient possible de calculer l'empreinte carbone par client, département ou application hébergée dans la CMDB.
• Refacturation (Chargeback) : En IT partagée, vous pouvez facturer les départements sur la base de leur consommation réelle mesurée sur le PDU, et non plus sur l'étiquette constructeur théorique.

‍

6. Déploiement par Straton DCIM : 4 étapes clés

‍

1. Normalisation des données (Hardware Model Normalization) : L'ITAM note HP DL380G10, la CMDB note DL380 Gen 10, et le DCIM note HPE ProLiant DL380 Gen10. Il est impératif de nettoyer les bases et de définir un dictionnaire matériel commun pour éviter les doublons lors de l'intégration API.
2. Mapping des attributs : Définissez strictement qui détient l'autorité de la donnée (Master). Exemple : la CMDB gère les adresses IP virtuelles, le DCIM gère l'adressage MAC physique.
3. Connectivité (API & Webhooks) : Utilisez l'API REST pour les synchronisations nocturnes (batchs d'inventaire) et privilégiez les Webhooks (Event-driven) pour les notifications de changement d'état en temps réel.
4. Acculturation et Processus : L'intégration technique ne fonctionne que si de nouveaux processus de Change Management sont adoptés conjointement par les équipes IT (Systèmes) et Facilities (Infrastructures physiques).

‍

Foire aux questions : Intégration DCIM et CMDB

‍

Le DCIM ou la CMDB : Lequel est la « Master Source of Truth » ?

Aucun des deux de manière absolue. L'architecture moderne repose sur la fédération de données : le DCIM est le Master sur la couche physique (Baies, Électricité, Câblage) et la CMDB est le Master sur la couche logique et ITSM (Applications, Contrats, Workflows).

‍

Comment synchroniser les données entre le DCIM et ServiceNow ?

L'intégration s'effectue généralement sur deux niveaux : des Webhooks sortants pour réagir en temps réel aux événements physiques (ex: un serveur est débranché), et des appels d'API REST bidirectionnels pour synchroniser quotidiennement les catalogues de matériels et les statuts des Configuration Items (CI).

‍

Un DCIM nouvelle génération peut-il remplacer une CMDB ?

Non, leurs rôles sont complémentaires. Un DCIM n'a pas vocation à gérer des contrats de licence logicielle, des renouvellements de garantie ou des workflows complexes de validation de tickets ITIL. La CMDB orchestre le service, le DCIM exécute et documente le matériel.

‍

‍

Sources :

Anthesis - Zombie Servers: Hunting Down The Lost Capital

Schneider Electric - How 6 AI Attributes Change Data Center Design

The Green Grid - PUE: A Comprehensive Examination of the Metric