Wie kann eine CMDB Server, GPUs, Container, Anwendungen, Business-Services und Owner miteinander verbinden?

Eine CMDB kann Server, GPUs, Container, Anwendungen, Business-Services und Owner miteinander verbinden, indem sie jedes Element als Configuration Item oder verwandtes operatives Objekt behandelt und dann typisierte Beziehungen zwischen ihnen pflegt. Der Wert entsteht dadurch, dass diese Beziehungen aktuell genug bleiben, um operative Fragen zu beantworten — nicht durch das Sammeln einer großen statischen Asset-Liste.

Eine nützliche Beziehungskette könnte so aussehen: Rack enthält Server, Server hostet GPU, Cluster enthält Node, Workload läuft in Container, Container verbraucht GPU, Anwendung hängt ab von Service, Service gehört zu Projekt, und Projekt hat einen Owner. Sobald diese Verknüpfungen bestehen, lässt sich ein Hardware-Alarm aufwärts bis zur Business-Auswirkung und seitwärts bis zur verantwortlichen Person zurückverfolgen.

Was soll eine CMDB eigentlich leisten?

Eine CMDB soll die Konfiguration einer IT-Umgebung sowie die Beziehungen abbilden, die den Betrieb von Services ermöglichen.

ServiceNow beschreibt seine CMDB als Mittel, um logische Darstellungen von Assets, Services und den Beziehungen zwischen ihnen aufzubauen. Genau dieser Fokus auf Beziehungen ist der Teil, der für moderne Betriebsabläufe am meisten zählt.

Ein statisches Inventar kann die Frage beantworten: „Wie viele Server besitzen wir?"

Eine beziehungsbewusste CMDB kann die Frage beantworten: „Welcher Service läuft auf diesem Server, welcher Container nutzt diese GPU, welchem Projekt gehört der Workload, und wer sollte den Incident zugewiesen bekommen?"

Das sind unterschiedliche Stufen operativen Werts.

Das zugrunde liegende Betriebsmodell nutzt aus diesem Grund fünf breite Dimensionen: Menschen, Assets, Aktivitäten, Compute und Business. Die Kategorien sind weniger wichtig als das Prinzip. Physische Ressourcen, logische Ressourcen, Arbeit, Verantwortung und Business-Verbrauch müssen miteinander verknüpft sein.

Für die Seite der automatischen Inventarisierung behandelt wie Rechenzentren automatisch präzise Hardware-Asset-Inventare entdecken und pflegen können, wie die zugrunde liegenden Datensätze aktuell bleiben.

Welche Objekte sollten modelliert werden?

Modellieren Sie die Objekte, die operative Entscheidungen beeinflussen.

Für physische Infrastruktur umfasst das üblicherweise Rechenzentren, Racks, Server, Netzwerkgeräte, Storage-Systeme, Stromversorgungstechnik und Kühltechnik.

Für Compute beziehen Sie physische Beschleunigerkarten ein, wo der Gesundheitszustand und die Zuweisung einzelner Karten eine Rolle spielen.

Für die Plattform-Ebene beziehen Sie, wo passend, Cluster, Nodes, virtuelle Maschinen, Container, Namespaces und Ressourcen-Pools ein.

Für Anwendungen beziehen Sie Application Services, Model Services, Datenbanken, Middleware, APIs und Business-Systeme ein, wo sie für die Auswirkungsanalyse relevant sind.

Für Menschen und Governance beziehen Sie verantwortliche Owner, Teams, Mandanten, Projekte, Anbieter und Wartungsbeziehungen ein.

Für Aktivitäten beziehen Sie Alarme, Arbeitsaufträge, Changes, Deployments, Inspektionen und größere Jobs ein, wo eine Beziehung zur Infrastruktur eine Rolle spielt.

Legen Sie nicht für jedes Feld oder jede Metrik ein Configuration Item an.

Eine CMDB ist keine Zeitreihendatenbank. Temperatur, Auslastung und Latenz gehören in Monitoring-Systeme. Die CMDB sollte das Objekt und seine Beziehungen identifizieren, damit Monitoring-Daten im Kontext interpretiert werden können.

Wie modellieren Sie einen physischen Server und seine GPUs?

Behandeln Sie den Server und jeden Beschleuniger als separate Objekte, wenn der Gesundheitszustand oder die Zuweisung auf Kartenebene relevant ist.

Der Server-Datensatz sollte Identitätsmerkmale wie Hersteller, Modell, Seriennummer, Management-Adresse, physischen Standort, Firmware-Baseline und Lifecycle-Status tragen.

Jeder GPU- oder NPU-Datensatz kann Hersteller, Modell, Serien- oder Geräte-Identifikator (sofern verfügbar), Slot- oder Bus-Position, Speicherkapazität, Firmware- oder Treiberbeziehung und Gesundheitszustand tragen.

Legen Sie dann eine Beziehung wie Server enthält Beschleuniger an.

Das macht Operationen auf Kartenebene möglich.

Meldet eine Karte einen nicht korrigierbaren Fehler, kann die Plattform den Host-Server identifizieren, ohne den gesamten Server als einziges Objekt zu behandeln.

Sie kann außerdem einen Server mit acht gesunden Karten von einem Server mit sieben gesunden Karten und einer degradierten Karte unterscheiden.

Die Beziehung wird noch nützlicher, wenn das Scheduling angebunden ist.

Mehr zur Normalisierung von Beschleuniger-Objekten über Hersteller hinweg finden Sie unter wie man GPUs und NPUs mehrerer Hersteller verwaltet.

Wie verbinden sich Container mit GPUs?

Container verbinden sich mit GPUs über Scheduler- und Runtime-Zuweisungsdaten.

Die physische Karte ist aus der Hardware-Discovery bekannt.

Der Node ist aus dem Cluster-Inventar bekannt.

Kubernetes oder ein anderer Scheduler weiß, welcher Workload dem Node zugewiesen wurde und welche Geräteressource zugeteilt wurde.

Die CMDB oder der Beziehungsdienst kann diese Quellen zu einer aktuellen Bindung zusammenführen.

Das Wichtige daran ist: Diese Beziehung verändert sich.

Ein Container kann beendet und neu erstellt werden. Ein Workload kann auf einen anderen Node umziehen. Eine GPU-Zuweisung kann freigegeben werden. Ein Node kann geleert werden.

Das bedeutet, dass Container-zu-GPU-Beziehungen nicht zuverlässig per manueller Eingabe gepflegt werden können.

Nutzen Sie ereignisgesteuerte oder häufige Synchronisation aus Scheduler- und Cluster-Zustand.

Behalten Sie Historie, wo die Incident-Analyse davon profitiert. Bei einer Post-Incident-Review müssen Sie unter Umständen wissen, welcher Container um 12:06 Uhr eine Karte belegte, auch wenn dieser Container nicht mehr existiert.

Wie verbinden sich Anwendungen und Business-Services mit Containern?

Anwendungen und Business-Services verbinden sich über Deployment-Metadaten, Service Discovery, Runtime-Topologie und explizite Ownership-Regeln.

Ein Container kann zu einem Kubernetes-Deployment oder -StatefulSet gehören.

Dieser Workload kann zu einem Namespace, einer Anwendung, einem Model Service oder einem Projekt gehören.

Ein API- oder Inference-Endpunkt kann dem Service zugeordnet werden, der ihn bereitstellt.

Der Service kann dann einer Geschäftsanwendung oder Fachabteilung zugeordnet werden.

Manche Beziehungen werden automatisch entdeckt. Andere brauchen explizite Metadaten.

Business-Ownership ist ein gutes Beispiel. Ein Scanner kann den verantwortlichen Owner nicht immer aus dem Netzwerkverkehr ableiten. Der Owner muss unter Umständen aus einem Projekt-Datensatz, einem Service-Katalog, Metadaten des Source-Repositorys oder einem freigegebenen manuellen Feld stammen.

Deshalb brauchen automatische und manuelle Quellen klare Autoritätsregeln.

Entdeckt die Automatisierung, dass ein Workload auf einen anderen Node umgezogen ist, sollte die Automatisierung diese Beziehung aktualisieren.

Ändert die Finanzabteilung den verantwortlichen Projekt-Owner, ist unter Umständen ein autorisierter Business-Datensatz die richtige Quelle.

Welche Beziehungstypen sollte eine CMDB verwenden?

Verwenden Sie Beziehungstypen, die operative Bedeutung ausdrücken.

Beispiele sind enthält, hostet, läuft auf, hängt ab von, verbunden mit, versorgt von, gekühlt von, gehört zu und verbraucht von.

Verwenden Sie nicht eine einzige generische „related to"-Verknüpfung für alles.

Die Ausbreitung von Auswirkungen hängt von Richtung und Bedeutung ab.

Hängt Anwendung A von Datenbank B ab, kann ein Datenbankausfall die Anwendung beeinträchtigen.

Enthält Rack R Server S, bedeutet ein Serverausfall nicht, dass das Rack ausgefallen ist.

Wird Server S vom PDU-Stromkreis P versorgt, kann ein Stromkreisausfall den Server beeinträchtigen.

Typisierte Beziehungen erlauben es der Plattform, über diese Unterschiede nachzudenken.

Sie machen Abfragen außerdem präziser.

Ein Operator kann fragen: „Zeige alle Business-Services, die von Nodes abhängen, die von dieser CDU gekühlt werden", oder: „Zeige den Owner jedes Workloads, der aktuell an diese GPU gebunden ist."

Wie halten Sie die Beziehungen korrekt?

Halten Sie Beziehungen korrekt, indem Sie automatische Discovery, Event-Synchronisation, Change-Workflows und zeitpunktbezogene Historie kombinieren.

Automatische Discovery ist am stärksten bei Fakten, die Maschinen direkt beobachten können: Seriennummern, Gerätemodelle, IP-Adressen, Rack-Positionen (wo instrumentiert), Cluster-Mitgliedschaft, Container-Zustand und Scheduler-Bindungen.

Change-Workflows eignen sich für kontrollierte Aktionen wie das Verschieben von Geräten, das Ändern von Ownership, das Ändern von Quotas oder das Ausmustern eines Geräts.

Event-Synchronisation übernimmt hochdynamische Beziehungen wie Pods und Container-Zuweisungen.

Snapshots helfen, die Vergangenheit zu rekonstruieren.

Korrektheit erfordert außerdem Konfliktregeln.

Angenommen, die CMDB sagt, ein Server steht in Rack A, aber das Discovery-System sagt Rack B.

Überschreiben Sie den Konflikt nicht stillschweigend, ohne zu wissen, welche Quelle maßgeblich ist.

Die Plattform sollte die Abweichung anzeigen, eine definierte Quellenpriorität anwenden oder eine Abgleichsaufgabe erstellen.

Eine vertrauenswürdige CMDB macht explizit deutlich, woher jedes Feld stammt.

Wie hilft eine CMDB bei der Incident-Impact-Analyse?

Eine CMDB unterstützt die Impact-Analyse, indem sie einen Fehler auf niedriger Ebene in einen durchlaufbaren Beziehungspfad verwandelt.

Stellen Sie sich vor, ein Beschleuniger meldet einen schwerwiegenden Speicherfehler.

Die Abwärtsanalyse kann die physische Karte, den Server, die Temperaturhistorie, die Firmware und zugehörige Hardware-Events untersuchen.

Die Aufwärtsanalyse folgt der aktuellen Bindung zum Container, dann zur Inference-Instanz, zum Model Service, zur Anwendung, zum Projekt und zur Fachabteilung.

Die horizontale Analyse identifiziert den verantwortlichen Owner, das O&M-Team, den Anbieter, den Wartungsvertrag und den aktuellen Arbeitsauftrag.

Das Ergebnis ist ein aussagekräftigerer Incident.

Statt „GPU-Fehler auf Node 17" kann der Incident sagen: „Diese Karte unterstützt zwei Inference-Instanzen. Ein Business-Service ist degradiert. Projekt X ist Owner des Service. Team Y ist verantwortlich. Die Karte steht unter Wartungsvertrag Z."

Das ist der praktische Wert von Beziehungsdaten.

Wie hilft eine CMDB beim Scheduling?

Eine CMDB kann Scheduling-Kontext liefern, den der Scheduler nicht selbst pflegt.

Der Scheduler kennt Ressourcen und Workload-Platzierung.

Die CMDB kann physischen und operativen Kontext ergänzen, etwa Failure Domain, Rack, Stromkreis, Kühlzone, Wartungsstatus, Business-Ownership und Hardware-Gesundheitszustand.

Zum Beispiel sieht ein Scheduler zwei Nodes vielleicht als gleichermaßen verfügbar an.

Die CMDB kann zeigen, dass einer davon für Wartung eingeplant ist oder zu einem Rack mit aktiver Kühlwarnung gehört.

Ob der Scheduler diese Information direkt nutzt, hängt von der Architektur ab, aber die Beziehungsgrundlage macht den Kontext verfügbar.

Das ist besonders nützlich in KI-Infrastruktur, wo der Gesundheitszustand auf Kartenebene und die physische Topologie lang laufendes Training beeinflussen können.

Wie hilft eine CMDB bei der Kostenzuordnung?

Eine CMDB unterstützt die Kostenzuordnung, indem sie Ressourcenverbrauch mit Projekten, Mandanten, Anwendungen und Ownern verknüpft.

Metering kann Ihnen sagen, dass eine GPU für 10 Stunden zugewiesen war.

Das Beziehungsmodell sagt Ihnen, welchem Projekt der Workload während dieser 10 Stunden gehörte.

API-Metering kann Ihnen sagen, wie viele Modellanfragen oder Tokens verbraucht wurden.

Das Beziehungsmodell verknüpft diese Aufrufe mit einem Key, Service, Projekt, Mandanten und verantwortlichen Team.

Ohne diese Beziehungsdaten können Kostensysteme zwar Summen liefern, tun sich aber schwer, die Zuordnung zu erklären.

Deshalb sollten Inventar, Scheduling, Service-Gateway und Metering dieselben Identifikatoren verwenden.

Ist eine CMDB dasselbe wie Asset-Management?

Nein. Asset-Management und CMDB überschneiden sich, aber ihre Fragestellungen unterscheiden sich.

Asset-Management konzentriert sich stark auf Eigentümerschaft, Beschaffung, finanziellen Lebenszyklus, Garantie, Standort und Ausmusterung.

CMDB konzentriert sich auf die Konfiguration und die Beziehungen, die für den Betrieb von Services nötig sind.

Ein physischer Server kann in beiden Sichten existieren.

Der Asset-Datensatz interessiert sich möglicherweise für Kaufdatum und Abschreibung.

Der Konfigurationsdatensatz interessiert sich möglicherweise dafür, zu welchem Cluster er gehört, welche Services von ihm abhängen und was betroffen wäre, wenn er ausfällt.

Die beiden sollten verknüpft sein, müssen aber nicht identisch sein.

Der breitere Kategorienvergleich wird behandelt unter was der Unterschied zwischen CMDB, DCIM, ITOM, AIOps und Cloud-Management-Plattformen ist.

Was ist das minimal sinnvolle CMDB-Modell?

Beginnen Sie mit Identität, Standort, Abhängigkeit, Ownership und Änderungshistorie.

Für eine moderne Compute-Umgebung bedeutet das, dass Sie Folgendes durchlaufen können sollten:

physischer Standort → Server → Beschleuniger → Cluster-Node → Workload → Anwendung oder Service → Projekt → Owner.

Sie brauchen nicht am ersten Tag jede mögliche Beziehung.

Ein kleines Beziehungsmodell, das korrekt bleibt, ist nützlicher als ein riesiges, dem niemand traut.

Ein Plattform-Beispiel, das um dieses gemeinsame Beziehungsprinzip herum gebaut ist, ist Sensaka.

Würde ich das von Grund auf implementieren, würde ich zuerst drei operative Fragen auswählen, etwa die Business-Auswirkung eines Hardwareausfalls, Ressourcen-Ownership und Kostenzuordnung. Ich würde nur die Beziehungen modellieren, die nötig sind, um diese Fragen zuverlässig zu beantworten. Sobald diese Kette vertrauenswürdig ist, würde ich sie erweitern.