CI relationships in the CMDB
Summarize
Summary of CI relationships in the CMDB
The Configuration Management Database (CMDB) in ServiceNow tracks not only Configuration Items (CIs) but also the relationships between them, enabling a dynamic understanding of how CIs interconnect. Each relationship involves two CIs—a parent and a child—and a relationship type that defines their connection. These relationships help you manage dependencies, resources, and operational impacts within your IT environment.
Show less
Relationships can be automatically discovered via Discovery or imported from external systems. You can also manually add, edit, or delete relationships using the CI relationship editor or the Unified Map in the CMDB Workspace app.
Key Features
- Dependent vs. Non-dependent Relationships: Dependent relationships (e.g., "Runs on") are used by the Identification and Reconciliation Engine (IRE) to avoid duplicate CIs by identifying dependencies. Non-dependent relationships track discovery source and last scan time, and can be safely deleted when no longer needed.
- Relationship Sources Tracking: Non-dependent relationships are recorded in the Relationship Sources [sysrelsource] table, which by default does not auto-populate to reduce load but can be enabled for detailed tracking.
- Key Relationship Types: Common relationship types include "Runs on," "Depends on," "Hosted on," "Contains," "Managed by," and others that represent typical infrastructure and application connections. These relationships help model resource allocation, management, and operational dependencies.
- Suggested Relationships: ServiceNow maintains a Suggested Relationship table that recommends appropriate relationship types based on CI classes, facilitating consistent and correct relationship modeling.
- Relationship Governance Rules: Rules enforce valid relationship types and directions between specific CI types to maintain CMDB integrity and prevent incorrect configurations.
- CI Relations Formatter and Relationship Editor: The CI relations formatter on the CI form provides multiple views of relationships and allows launching the relationship editor for creating, modifying, or deleting relationships efficiently.
- Security Controls: Applying access controls to both the CI Relationship table and the edit operation ensures secure management of CI relationships.
- CI Relation Rollups: Enables aggregation functions (sum, count, max, min, mean) on relationship types to support reporting and analysis.
Practical Application for ServiceNow Customers
Understanding and managing CI relationships in the CMDB allows you to:
- Maintain accurate and dynamic visibility into your IT environment dependencies and resource allocations.
- Leverage automated discovery and import to populate and keep relationships current, reducing manual effort.
- Use governance rules and suggested relationships to ensure relationship integrity and consistency.
- Utilize tools like the CI relationship editor and Unified Map to efficiently manage complex relationship networks.
- Apply security best practices to protect relationship data within your CMDB.
- Use relationship rollups for aggregated insights, supporting better decision-making and impact analysis.
The CMDB, in contrast to a static asset list, helps you track not only the configuration items (CIs) within your system, but also the relationships between those items.
- Parent CI
- Child CI
- Type of the relationship that links both CIs
- Server1 is the child CI
- Server2 is the parent CI
- [Managed by] is the relationship type
For example, a web application might read data from an instance of Oracle, which in turn might depend on a piece of underlying hardware. Most CIs in a CMDB have multiple relationships to other CIs, users, and groups.
The relationships between CIs can be automatically discovered. If you use Discovery, many relationships can be automatically loaded into the system through the discovery process. If you import your data from another system, you get some form of relationships.
You can add to automatically discovered relationships, create relationships, or edit relationships for a CI by launching the CI relationship editor from the CI form. As an alternative to the CI relationship editor, Unified Map in the CMDB Workspace store app provides the latest functionality for editing CI relationships. For more information, see Edit relationships in Unified Map.
Dependent and non-dependent relationships
Dependent relationships, such as tomcat RunsOn Hardware, are used by the Identification and Reconciliation Engine (IRE) to identify dependent CIs. The IRE avoids duplicate entries of CIs into your Configuration Management Database (CMDB) by leveraging these relationships to determine if a recently discovered CI is already in the CMDB.
For non-dependent relationships, the CMDB tracks the discovery source and the last scanned time in the Relationship Sources [sys_rel_source] table. Non-dependent relationships aren't used for CI identification, and can be deleted when no longer needed.
To avoid burdening your IRE with excessive load, by default, the Relationship Sources [sys_rel_source] table doesn't auto-populate. If you want to track full information on non-dependent relationships, you can change the default using the glide.identification_engine.populate_sys_rel_source property.
Dependent relationships are used for CI identification, so they shouldn't be directly deleted as they aren't tracked.
Information in the Relationship Sources [sys_rel_source] table can be used to decide if it’s safe to delete a potentially non-dependent relationship. For example, a discovery source, which is attempting to delete a non-dependent relationship can confirm that:
- There are no other data sources for that relationship.
- The relationship wasn't updated for some specified length of time and therefore is no longer needed.
When a non-dependent relationship is deleted from the CI Relationship [cmdb_rel_ci] table, all cascading corresponding records in the Relationship Sources [sys_rel_source] table are deleted.
Key relationships
| Parent | Child | Description |
|---|---|---|
| Applicative Flow To | Applicative Flow From | Connections between endpoint CIs. Note: For internal use only (service model). |
| Connects to | Connected by | Network Connections between elements that are talking to each other. Examples: Workstation to switch, switch to switch, kubernetes workload to service. |
| Contains | Contained by | Typically a containment relationship (CI to contained CI). The child CI typically has a single parent CI with this relationship type. Examples: Tomcat to Tomcat WAR, VMware Datacenter contains Network. |
| Defines resources for | Gets resources from | Parent CI defines/gets resources from a child CI. Example: VMware - Resource pool gets resources from ESX Server. |
| Depends on | Used by | Parent CI depends on child CI. Meaning that problem/change in the child CI may impact the parent CI. |
| Hosted on | Hosts | Hosting relationship between an element and its host. Examples: Cloud resource to logical data center, k8s workload to k8s cluster. |
| Implement End Point To | Implement End Point From | Endpoint to CI that exposes this endpoint. Note: For internal use only (service model). |
| Manages | Managed by | Typically used where one CI manages one or more other CIs. Example: vCenter manages vCenter Datacenter. |
| Members | Member of | Typically used with clusters where a cluster node is a member of a cluster. Example: ESXi Server is a member of vCenter Cluster. |
| Owns | Owned by | Usually a containment relationship (CI to owned CI). The child CI typically has a single parent with this relationship type. |
| Runs on | Runs | Typically between a CI that represents a software application, to the hosting hardware/VM. Example: Tomcat 'Runs on' Linux server. |
| Use End Point To | Use End Point From | From the CI to an outgoing endpoint. Note: For internal use only (service model). |