DCIM, CMDB oder keines von beidem? Was Unternehmen für das Management ihrer Rechenzentrumsinfrastruktur brauchen
/ Autor: Oliver Lindner / Lesedauer: etwa 6 Minuten
Eine Kühleinheit in einem Ihrer Rechenzentren fällt an einem Freitagnachmittag aus. Das Monitoring System schlägt innerhalb weniger Sekunden Alarm. Die CMDB listet die Server in diesem Raum. Der Service Desk eröffnet einen Incident. Eine Stunde später kann trotzdem niemand im Unternehmen mit Sicherheit sagen, welche kundenorientierten Services gefährdet sind, welche davon über Redundanzen verfügen und bei welchen Verträgen Vertragsstrafen drohen, wenn die Störung bis zum Abend anhält.
Jedes System hat seine Aufgabe erfüllt. Das Problem ist, dass jedes System nur einen Teil der Infrastruktur kennt, während keines die gesamte Infrastruktur überblickt. Genau diese Lücke zwischen Systemen, die jeweils korrekte Informationen liefern, und einer Organisation, die trotzdem eine einfache Frage nicht beantworten kann, soll das Infrastrukturmanagement schließen. Genau deshalb ist die Lösung weder ein weiteres DCIM Tool noch eine größere CMDB.
Eine Infrastruktur, viele Teilansichten
Die meisten Unternehmen dokumentieren ihre Infrastruktur an vier oder fünf voneinander unabhängigen Stellen. Das Gebäudemanagementsystem kennt Stromversorgung, Kühlung und Access. Die Monitoring Plattform weiß, was in Betrieb, ausgefallen oder überhitzt ist. Die CMDB kennt Configuration Items und die zugehörigen Tickets. Das Netzwerkteam verfügt über ein eigenes Inventory, das Verkabelungsteam arbeitet mit Plänen und irgendwo gibt es eine Tabelle mit Vertragsdetails oder Kundenzuordnungen.
Jede dieser Quellen bietet eine legitime und wichtige Sicht auf den Betrieb des Rechenzentrums. Doch keine von ihnen kann die Beziehungen zwischen diesen Informationen herstellen. Dadurch lässt sich nicht zuverlässig nachvollziehen, welche Stromversorgung welches Rack versorgt, welches Rack welchen Server beherbergt, welcher Server welche Anwendung betreibt und welcher Business Service ausfällt, wenn ein Glied dieser Kette versagt. Diese Abhängigkeiten sind nirgendwo vollständig hinterlegt, weil kein einzelnes System dafür entwickelt wurde oder dafür vorgesehen ist, diese Informationen abzubilden.
Passende Lösung
Die Folgen dieser Lücke zeigen sich an drei Stellen. Beim Incident Management muss die Auswirkung eines Ausfalls manuell rekonstruiert werden. Bei der Change Planung wird das Risiko eines Wartungsfensters geschätzt, anstatt es zuverlässig bewerten zu können. Und bei Compliance Anforderungen stellen Auditoren im Rahmen von Regularien wie der EU NIS2 Richtlinie und DORA, dem Cybersecurity Act in Singapur oder der bevorstehenden US-amerikanischen CIRCIA Meldepflicht Fragen, die sich über sämtliche Systemgrenzen hinweg erstrecken und eine dokumentierte und aktuelle Antwort erwarten.
Kontext ist der entscheidende Faktor, nicht Daten
Es liegt nahe, dieses Problem mit noch mehr Daten lösen zu wollen. Doch zusätzliche Sensoren, höhere Abfrageintervalle und ein weiteres Dashboard helfen nicht weiter. Was im Szenario am Freitagnachmittag fehlte, war keine Messung. Die Temperaturmessung war korrekt. Was fehlte, war Kontext: die Möglichkeit, ein physisches Ereignis innerhalb der Infrastruktur bis zu den betroffenen Services und Verpflichtungen nachzuverfolgen und ebenso wichtig eine geschäftliche Fragestellung bis hinunter zu den physischen Assets zu verfolgen, die diesen Service bereitstellen.
Dieser Kontext hat einige entscheidende Eigenschaften. Er erstreckt sich über mehrere Ebenen, von der Gebäudetechnik über physische Komponenten, Netzwerk, Virtualisierung und Anwendungen bis hin zum Business Service. All diese Ebenen werden in einem zusammenhängenden Modell abgebildet und nicht über voneinander getrennte Abfragen miteinander verbunden.
Das Modell unterscheidet außerdem zwischen Plan- und Ist-Zustand. Dadurch können Änderungen bereits vor ihrer Umsetzung bewertet werden und nicht erst im Nachhinein. Auch Konnektivität wird als eigenständiges Element behandelt. Der Kabelweg von einem Port über ein Patchpanel bis zur Übergabe an einen Carrier ist Teil der Abhängigkeitskette und kein bloßer Anhang.
Dies bildet auch die Grundlage für zwei sehr unterschiedliche Bereiche, die zunehmend auf diesen Kontext angewiesen sind. Compliance Reporting benötigt ihn, weil Resilienztests, die Validierung der Business Continuity und die CO₂ Berichterstattung nach Scope 1 bis 3 auf derselben Abhängigkeitsstruktur basieren. Ein Generator, ein Kältemittel und der CO₂ Ausstoß gehören zu einem gemeinsamen Infrastruktur Bestand und nicht zu voneinander getrennten Reports.
Auch KAI benötigt diesen Kontext. Ein Assistent, der gefragt wird: „Welche Auswirkungen hat der Ausfall dieses Stromanschlusses?“, kann nur so gut antworten wie das Modell, auf dem seine Antwort basiert. Daten zeigen, was passiert. Kontext zeigt, was es bedeutet.
Konsolidieren statt ersetzen
Eine einzige Plattform, die alles erledigt, das Gebäude steuert, den Service Desk betreibt, die Infrastruktur überwacht und gleichzeitig als zentrale Datenquelle dient, ist nicht die Antwort. Enterprise Infrastruktur Umgebungen sind heterogen, weil die darin eingesetzten spezialisierten Tools aufgrund ihrer jeweiligen Funktionstiefe benötigt werden und unverzichtbar bleiben.
Der bessere Ansatz ist eine Management Ebene, die zwischen diesen operativen Systemen und den darüberliegenden Business Systemen angesiedelt ist. Diese Ebene übernimmt die Informationen, die bereits im Gebäudemanagementsystem, in der Monitoring Plattform und in Discovery Tools vorhanden sind, und hält das, was diesen Systemen fehlt: ein einheitliches Asset Modell und einen Dependency Graph, der diese Informationen miteinander verbindet.
Dieses Modell wird anschließend für IT Service Management, Compliance und Sustainability Reporting sowie zunehmend auch für KI bereitgestellt.
Genau für diese Management Ebene wurde FNT Command entwickelt, mit einem bewusst definierten Funktionsumfang. FNT Command steuert weder Ihre Kühlanlagen noch ersetzt es Ihren Service Desk. Stattdessen dokumentiert und verwaltet es die Infrastruktur, die Ihre IT Services bereitstellt, darunter Facility Assets, IT Assets, Netzwerk, Verkabelung und Outside Plant, in einem gemeinsamen Modell einschließlich der Abhängigkeiten und integriert sich in Ihre bestehende Systemlandschaft.
FNT Command wird von mehr als 500 Unternehmen eingesetzt und blickt auf 30 Jahre Erfahrung zurück. Mit einer Bibliothek von rund 85.000 Komponenten und mehr als 200 bidirektionalen Integrationen im Produktivbetrieb wurde die Lösung in einer aktuellen Analystenbewertung dieses Marktes als Major Player eingestuft. Als besondere Stärken werden das domänenübergreifende Modell, die detaillierte Abbildung von Konnektivität und die Integrationsarchitektur hervorgehoben.
Der praktische Nutzen dieses Ansatzes zeigt sich vor allem in der eingesparten Zeit. In Umgebungen, in denen die Dokumentation sowohl logische als auch physische Ebenen umfasst und Abhängigkeiten erfasst sind, lassen sich Impact Assessments, die zuvor Tage dauerten, innerhalb weniger Stunden durchführen. Fragen wie im beschriebenen Szenario am Freitagnachmittag können beantwortet werden, bevor die erste Runde im Incident Call abgeschlossen ist.
Zwei Fragen als Praxistest für Ihre Infrastruktur
Sie benötigen keine Tool Evaluierung, um herauszufinden, ob diese Lücke in Ihrer Infrastruktur besteht. Zwei Fragen reichen aus.
- Kann ein System in Ihrem Unternehmen heute für Sie aufzeigen, welche Business Services von Ihrem schwächsten Stromanschluss abhängig sind?
- Wenn beim nächsten Audit wissen gefragt wird, wie sich ein technischer Ausfall auf einen regulierten Service auswirken würde: Kommt die Antwort aus einem gepflegten Modell oder aus einem Meeting?
Wenn die zweite Antwort „aus einem Meeting“ lautet, fehlt nicht mehr Monitoring und auch keine größere CMDB. Was fehlt, ist die Management Ebene dazwischen.
Erfahren Sie mehr darüber, wie FNT Command hybride digitale Infrastrukturen über Rechenzentrum, IT, Netzwerk und Verkabelung hinweg verwaltet: fntsoftware.com.