CMDB-Software
Eine CMDB ist nur dann nützlich, wenn die Daten stimmen. Sensaka baut die Configuration Management Database aus Live-Infrastrukturdaten auf – kontinuierlich entdeckt, nicht manuell gepflegt.
Die meisten CMDBs scheitern aus einem Grund
Die Daten veralten. Manuelle Aktualisierungen, unvollständige Discovery und schwache Integration machen die Datensätze mit der Zeit unzuverlässig. Sobald Teams der CMDB nicht mehr vertrauen, hören sie auf, sie zu nutzen – und jeder nachgelagerte Prozess, der darauf aufbaut, erbt dieselben blinden Flecken.
Die Branche weiß das seit Jahren: Analysten berichten übereinstimmend, dass die meisten CMDB-Initiativen keinen Mehrwert liefern, und das Scheitern folgt fast immer demselben Muster: Die Datenbank beschreibt die Umgebung so, wie sie beim letzten manuellen Update war, nicht wie sie jetzt ist. Ein Incident Manager, der einen Datensatz zweimal prüft und ihn zweimal falsch vorfindet, wird ihn nie wieder prüfen. Genauigkeit ist kein Feature einer CMDB, sie ist das eigentliche Produkt.
Kontinuierliche Discovery, drei Ebenen tief
Sensaka befüllt und pflegt die CMDB durch agentenlose, geplante Discovery über drei Ebenen der Umgebung hinweg. Wo automatisierte Quellen und manuelle Aufzeichnungen voneinander abweichen, entscheiden Autoritätsregeln, welche Quelle gilt – und jede Änderung wird mit vorherigem Wert, neuem Wert, Quelle und Zeitstempel erfasst, sodass sich die Historie eines Configuration Item für jeden Zeitpunkt rekonstruieren lässt.
Netzwerk- & Betriebssystemebene
SNMP, SSH/CLI, WMI und APIs erfassen Gerätekonfiguration, Schnittstellen, Betriebssysteme und installierte Software.
Hardware-Ebene (Out-of-Band)
Redfish, IPMI, iDRAC, iLO, XCC und iBMC melden das Inventar auf Komponentenebene: CPU, Arbeitsspeicher, Festplatten, Firmware, Seriennummern – selbst wenn das Betriebssystem nicht erreichbar ist.
Virtualisierungs- & Datenebene
Hypervisor-APIs und JDBC ordnen VMs den Hosts, Datenbanken den Servern und Anwendungen der darunterliegenden Infrastruktur zu.
Physische und logische Beziehungen gemeinsam
Die meisten CMDB-Tools bilden die logische Welt ab – VMs, Services, Anwendungen – und enden beim Hypervisor. Der Konfigurationsgraph von Sensaka geht weiter nach unten: welcher physische Server die VM hostet, welches Rack und welche U-Position den Server aufnimmt, welche PDU und welcher Stromkreis ihn versorgen und welche Komponenten darin verbaut sind. Genau diese Ebene ist entscheidend, wenn ein Hardwarefehler, ein Stromereignis oder eine Rechenzentrumsmigration ansteht.
Derselbe Graph reicht ebenso nach oben bis zu Business Services: Ein Alarm zu einer Festplatte wird zu „der Datenbank-Host des Zahlungsservices hat eine ausfallende Festplatte in Rack B-12“ statt zu einem bloßen Hardware-Ereignis. Impact-Analyse, Change-Planung und Incident-Routing greifen alle auf dieses eine Modell zu.
Drei Wege, eine CMDB zu betreiben
| Dimension | Manuell / Tabellenkalkulation | Agentenbasierte CMDB | Sensaka |
|---|---|---|---|
| Wie Datensätze entstehen | Von Engineers manuell eingetragen | Agent-Meldungen aus dem Betriebssystem heraus | Agentenlose Discovery über Netzwerk-, Betriebssystem- und BMC-Hardware-Schnittstellen |
| Hardware-Transparenz | Was auch immer die Tabelle sagt | Nur, was das Betriebssystem preisgibt | Auf Komponentenebene, über Out-of-Band-Management – unabhängig vom Betriebssystem |
| Physischer Standort | Oft fehlend oder veraltet | Nicht erfasst | Rechenzentrum, Raum, Rack und U-Position als Beziehungen erfasst |
| Risiko veralteter Daten | Hoch: veraltet innerhalb von Wochen | Mittel: Lücken dort, wo keine Agenten installiert sind | Niedrig: geplante Re-Discovery mit Änderungshistorie |
| Nachgelagerte Nutzung | Nachschlagedokument | Monitoring-Ergänzung | Versorgt ITSM, Impact-Analyse und Automatisierung mit Live-Kontext |
Wofür Teams es nutzen
Impact-Analyse vor Changes
Ein Change Request an einem Core-Switch zeigt, welche Server, VMs, Datenbanken und Business Services dahinterstehen – bevor jemand das Gerät anfasst.
Schnellere Incident-Triage
Ein Alarm kommt mit angehängtem Konfigurationskontext an: was das Gerät ist, wo es verbaut ist, was darauf läuft und wer den Service verantwortet.
Nachweise für Audit und Compliance
Die Konfigurationshistorie beantwortet „was hat sich wann geändert“ mit erfassten Werten, Zeitstempeln und Quellen – nicht aus dem Gedächtnis rekonstruiert.
Asset-Abgleich
Die entdeckte Realität wird mit dem erfassten Inventar abgeglichen, um Geister-Assets, fehlende Datensätze und Standortabweichungen aufzudecken.
Planung des Hardware-Lebenszyklus
Datensätze auf Komponentenebene – Modelle, Firmware, garantierelevante Seriennummern – unterstützen die Erneuerungsplanung auf Basis dessen, was tatsächlich installiert ist.
Was eine vertrauenswürdige CMDB ermöglicht
Das CMDB-Modul ist Teil der iDCOS-Plattform neben ITSM und Automatisierung und ergänzt Data Center Asset Management sowie IT Asset Management. Für GPU- und AI-Umgebungen erweitert die AI Infrastructure CMDB dasselbe Modell auf Beschleuniger, Cluster und Workloads.
Häufige Fragen zu CMDB-Software
Was ist CMDB-Software?
CMDB-Software pflegt eine Configuration Management Database: eine strukturierte Erfassung der Configuration Items Ihrer Infrastruktur (Server, Netzwerkgeräte, Storage, VMs, Anwendungen) und – entscheidend – der Beziehungen zwischen ihnen. Sie beantwortet Fragen wie „Was läuft auf diesem Host?“ und „Was fällt aus, wenn dieser Switch ausfällt?“, die eine flache Asset-Liste nicht beantworten kann.
Wie hält Sensaka die CMDB-Daten aktuell und korrekt?
Durch kontinuierliche automatisierte Discovery statt manueller Erfassung. Sensaka sammelt Konfigurationsdaten über SNMP, SSH, APIs, JDBC und – für eine CMDB ungewöhnlich – Out-of-Band-Hardware-Schnittstellen wie Redfish, IPMI, iDRAC, iLO und iBMC. Datensätze werden nach einem geplanten Sync-Rhythmus aktualisiert, und die Änderungshistorie hält fest, was sich wann und aus welcher Quelle geändert hat.
Deckt die CMDB die physische Infrastruktur ab oder nur die IT?
Beides, in einem gemeinsamen Beziehungsgraphen. Physisch: Rechenzentrum, Raum, Rack, U-Position, Strompfad und Hardwarekomponenten bis hinunter zu einzelnen Festplatten und Speichermodulen. Logisch: VMs, Betriebssysteme, Datenbanken, Middleware, Container und die von ihnen unterstützten Business Services.
Lässt sich die CMDB von Sensaka in unsere bestehenden ITSM-Tools integrieren?
Ja. Die CMDB ist die Datenebene der iDCOS-Plattform, die ein eigenes ITSM-Modul (Incident, Problem, Change, Release, SLA) umfasst, und kann bestehende Service-Management-Tools zusätzlich über APIs versorgen, sodass Tickets und Changes mit korrektem Konfigurationskontext versehen sind.
Was unterscheidet das von ServiceNow oder anderen Enterprise-CMDBs?
Zwei Dinge: die Hardware-Ebene und der Preis. Die Discovery von Sensaka reicht über BMC-Schnittstellen unter das Betriebssystem, sodass Konfigurationsdaten in der physischen Realität verankert bleiben – Rack-Positionen, Strompfade, Seriennummern von Komponenten – und nicht nur das widerspiegeln, was ein Agent innerhalb des Betriebssystems meldet. Zudem ist das CMDB-Modul für Mid-Market-Teams bepreist (ab $80 pro Knoten und Jahr) statt für Enterprise-Verträge.