CI-Beziehungen in der CMDB

  • Freigeben Version: Zurich
  • Aktualisiert 31. Juli 2025
  • 3 Minuten Lesedauer

    • Im Gegensatz zu einer statischen Asset-Liste können Sie mit der CMDB nicht nur die Configuration Items (CIs) in Ihrem System, sondern auch die Beziehungen zwischen diesen Elementen nachverfolgen.

    Eine Beziehung in der CMDB besteht aus zwei CIs und einem Beziehungstyp:
    • Übergeordnete CI
    • Untergeordnete CI
    • Typ der Beziehung, die beide CIs verknüpft
    Beispielsweise in der Beziehung [Server1] [Managed by] [Server2]:
    • Server1 ist das untergeordnete CI
    • Server2 ist das übergeordnete CI
    • [Managed by] ist der Beziehungstyp

    Beispielsweise kann eine Webanwendung Daten aus einer Instanz von Oracle lesen, die wiederum von einer zugrunde liegenden Hardware abhängen kann. Die meisten CIs in einer CMDB haben mehrere Beziehungen zu anderen CIs, Benutzern und Gruppen.

    Die Beziehungen zwischen CIs können automatisch erkannt werden. Wenn Sie Discovery verwenden, können viele Beziehungen durch den Discovery Prozess automatisch in das System geladen werden. Wenn Sie Ihre Daten aus einem anderen System importieren, erhalten Sie eine Art Beziehung.

    Sie können automatisch erkannte Beziehungen hinzufügen, Beziehungen erstellen oder Beziehungen für ein CI bearbeiten, indem Sie starten CI-Beziehungs-Editor Aus dem CI-Formular. Als Alternative zum CI-Beziehungs-Editor Einheitliche Übersicht In Store-App CMDB-Arbeitsbereich Bietet die neuesten Funktionen zum Bearbeiten von CI-Beziehungen. Weitere Informationen finden Sie unter Bearbeiten Sie Beziehungen in der einheitlichen Übersicht .

    Abhängige und nicht abhängige Beziehungen

    Abhängige Beziehungen , Z. B. Tomcat RunsOn-Hardware, werden von der Identification and Reconciliation Engine (IRE) verwendet, um abhängige CIs zu identifizieren. Die IRE vermeidet doppelte Einträge von CIs in Ihrer Configuration Management Database (CMDB), indem sie diese Beziehungen nutzt, um festzustellen, ob sich ein kürzlich erkanntes CI bereits in der CMDB befindet.

    Bei nicht abhängigen Beziehungen verfolgt die CMDB die Discovery-Quelle und die Zeit des letzten Scans in der Tabelle „Beziehungsquellen“ [sys_rel_Source]. Nicht abhängige Beziehungen werden nicht für die CI-Identifizierung verwendet und können gelöscht werden, wenn sie nicht mehr benötigt werden.

    Um eine übermäßige Belastung Ihrer IRE zu vermeiden, wird die Tabelle „Beziehungsquellen“ [sys_rel_Source] standardmäßig nicht automatisch ausgefüllt. Wenn Sie vollständige Informationen zu nicht abhängigen Beziehungen nachverfolgen möchten, können Sie den Standard mit der Eigenschaft Glide.Identification_Engine.populate_sys_rel_Source ändern.

    Abhängige Beziehungen Werden zur CI-Identifizierung verwendet, daher sollten sie nicht direkt gelöscht werden, da sie nicht nachverfolgt werden.

    Informationen in der Tabelle „Beziehungsquellen“ [sys_rel_Source] können verwendet werden, um zu entscheiden, ob das Löschen einer potenziell nicht abhängigen Beziehung sicher ist. Beispielsweise kann eine Discovery-Quelle, die versucht, eine nicht abhängige Beziehung zu löschen, Folgendes bestätigen:

    • Für diese Beziehung sind keine anderen Datenquellen vorhanden.
    • Die Beziehung wurde für einen bestimmten Zeitraum nicht aktualisiert und wird daher nicht mehr benötigt.

    Wenn eine nicht abhängige Beziehung aus der Tabelle „CI-Beziehung“ [cmdb_rel_ci] gelöscht wird, werden alle kaskadierenden entsprechenden Datensätze in der Tabelle „Beziehungsquellen“ [sys_rel_Source] gelöscht.

    Schlüsselbeziehungen

    Die folgende Tabelle enthält Beschreibungen für einige Schlüssel CMDB Beziehungen.
    Übergeordnet Untergeordnetes Element Beschreibung
    Flow nach Anwendungs-Flow von

    Verbindungen zwischen Endpunkt-CIs.

    Hinweis:
    Nur zur internen Verwendung (Servicemodell).
    Verbunden mit Verbunden von

    Netzwerkverbindungen zwischen Elementen, die miteinander kommunizieren.

    Beispiele: Zu wechselnde Workstation, Wechsel zu Wechsel, kubernetes-Arbeitsauslastung zu Service.
    Enthält Enthalten in

    Normalerweise eine Containment-Beziehung (CI zu enthaltenem CI). Das untergeordnete CI hat normalerweise ein einzelnes übergeordnetes CI mit diesem Beziehungstyp.

    Beispiele: Tomcat-zu-Tomcat-WAR, VMware-Rechenzentrum enthält Netzwerk.
    Definiert Ressourcen für Erhält Ressourcen von

    Übergeordnetes CI definiert/ruft Ressourcen von einem untergeordneten CI ab.

    Beispiel: VMware – Ressourcenpool ruft Ressourcen von ESX Server ab.
    Abhängig von Verwendet von Übergeordnetes CI hängt vom untergeordneten CI ab. Bedeutet, dass ein Problem/eine Änderung im untergeordneten CI sich auf das übergeordnete CI auswirken kann.
    Gehostet auf Hosts

    Hosting-Beziehung zwischen einem Element und seinem Host.

    Beispiele: Cloud-Ressource zum logischen Rechenzentrum, k8s-Arbeitsauslastung zum k8s-Cluster.
    Endpunkt implementieren in Endpunkt implementieren von

    Endpunkt für CI, das diesen Endpunkt bereitstellt.

    Hinweis:
    Nur zur internen Verwendung (Servicemodell).
    Verwaltet Verwaltet von

    Wird normalerweise verwendet, wenn ein CI ein oder mehrere andere CIs verwaltet.

    Beispiel: VCenter verwaltet vCenter Datacenter.
    Mitglieder Mitglied von

    Wird normalerweise mit Clustern verwendet, bei denen ein Clusterknoten Mitglied eines Clusters ist.

    Beispiel: ESXi-Server ist Mitglied des vCenter-Clusters.
    Eigentümer von Eigentum von Normalerweise eine Containment-Beziehung (CI zu CI im Besitz). Das untergeordnete CI hat normalerweise ein einzelnes übergeordnetes CI mit diesem Beziehungstyp.
    Wird ausgeführt auf Wird ausgeführt

    Normalerweise zwischen einem CI, das eine Softwareanwendung darstellt, und der Hosting-Hardware/VM.

    Beispiel: Tomcat „wird auf“ Linux-Server ausgeführt.
    Endpunkt verwenden an Endpunkt verwenden von

    Vom CI zu einem ausgehenden Endpunkt.

    Hinweis:
    Nur zur internen Verwendung (Servicemodell).