Executive summary
ServiceNow CMDB ships with roughly a dozen out-of-the-box classes for modeling storage infrastructure. They look similar at first glance — cmdb_ci_disk versus cmdb_ci_storage_disk, cmdb_ci_storage_container versus cmdb_ci_storage_pool — and the documentation rarely explains why both exist. The result: integrations and Discovery patterns end up populating the wrong class, the relationship chain breaks, and impact analysis quietly underestimates blast radius.
This paper is a practical reference for the people building, configuring, or auditing storage models in CMDB. It walks each class in turn, explains what it represents in real hardware terms, calls out the relationships that hold the model together, and flags the mistakes that show up most often in production environments.
|
WHAT YOU'LL TAKE AWAY • Clear definitions for every storage class, mapped to vendor terminology you actually see in the field (NetApp, Dell EMC, Pure, Hitachi). • The relationship chain that holds the model together, from physical disk to logical volume. • A diagnostic checklist for the modeling mistakes that quietly break impact analysis. |
Why this disambiguation matters
Storage is the layer where CMDB modeling errors hurt most. A misconfigured server CI is annoying. A misconfigured storage CI silently corrupts every impact map that depends on it. When the relationship chain from disk to enclosure to pool to volume is broken — even by one missing layer — the platform can't tell you which services share a failed aggregate, which hosts ride on a degraded controller, or whether a cluster failover actually protects what you think it protects.
The classes covered here exist for a reason. Each one represents a distinct piece of physical or logical reality in the storage system. Skipping a layer to save time during integration always costs more later, when someone asks for a capacity report or an impact analysis and the data simply isn't there to answer.
The storage class reference
The sections that follow walk each storage class in the order you'd encounter them building a model from the ground up — from the physical appliance, through the chassis and disks, into the logical pools and volumes, and finally up to the cluster constructs that group systems together.
cmdb_ci_storage_server
Represents the physical or virtual storage appliance itself — the "brain" of a storage system. Think of a NetApp filer, a Dell EMC PowerStore array, or a Pure Storage FlashArray. This is the device that manages and serves storage to consumers.
It extends cmdb_ci_server and carries attributes like firmware version, vendor, model, serial number, and management IP. In implementation, this is your anchor CI — relationships fan out from here to everything else.
cmdb_ci_storage_enclosure
The physical chassis or shelf that houses drives. A single storage server might connect to multiple enclosures — think a disk shelf or JBOD expansion tray bolted into the rack.
It models the physical container: slot count, form factor, power. Not the logical storage. Use this class when you need to track hardware lifecycle, rack position, or capacity planning at the physical shelf level. It relates to the storage server via Contains::Contained by or Connects to relationships.
cmdb_ci_disk
The generic base class for a physical disk drive — any spinning or solid-state drive in any server, not just storage arrays. A disk inside a standard compute server's local RAID would land here. It tracks serial number, size, interface type, RPM. Broadly applicable, but not storage-array-specific.
cmdb_ci_storage_disk
Extends cmdb_ci_disk and is specifically scoped to disks that live inside a storage system — disks managed by a storage server, seated in a storage enclosure.
The distinction matters because storage disks carry additional context: RAID group membership, disk pool assignment, wear level for SSDs, and the relationship chain back through enclosure to storage server. In practice, if Discovery is pulling from a SAN array, the disks land here — not in the generic cmdb_ci_disk.
cmdb_ci_storage_container
The logical construct — an aggregate, volume group, or similar abstraction that sits between raw disks and the volumes or LUNs presented to consumers.
It groups cmdb_ci_storage_disk records into a logical tier and is the parent from which cmdb_ci_storage_volume records are carved. This is where you model thin provisioning policies, RAID levels at the pool layer, and capacity utilization.
cmdb_ci_storage_pool
Represents a vendor-defined pool of raw storage capacity — the lowest-level logical grouping of physical disks before any RAID or provisioning policy is applied. Think of it as the "disk group" or "RAID group" layer.
On a NetApp system, this maps to a RAID group within an aggregate. On Dell EMC, it's the disk pool or RAID group that the system automatically manages. On Hitachi, it's the parity group.
Storage container vs. storage pool
This is the pair that trips people up most often. The key distinction is one of abstraction level.
|
THE RELATIONSHIP CHAIN IN PLAIN TERMS cmdb_ci_storage_disk → grouped into cmdb_ci_storage_pool (RAID group) → aggregated into cmdb_ci_storage_container (pool/aggregate) → carved into cmdb_ci_storage_volume. |
storage_pool is closer to the metal. It's about which disks are bound together and what RAID protection they use. storage_container is the higher-level abstraction that pools can feed into — the aggregate, the storage pool (in Dell EMC terminology, confusingly), or the tier that actually gets carved into volumes.
Not every vendor populates both
In many real-world implementations you'll see either storage_pool or storage_container populated, but not both. It depends on how the storage array exposes its internals via SMI-S or REST API.
NetApp Discovery tends to populate both because NetApp's architecture has a clear RAID group → aggregate hierarchy. Simpler arrays that auto-manage their RAID — Pure Storage, for example — may skip the pool layer entirely and go straight from disks to container.
Cluster and high-availability classes
cmdb_ci_storage_cluster
A logical grouping of storage systems that operate together as a unified entity for high availability, failover, or scale-out. Think of a NetApp MetroCluster pair, a Dell EMC VPLEX cluster, or a Pure ActiveCluster.
The cluster itself is the CI — it's the thing your hosts "see" as a single storage target, even though underneath there are two or more physical arrays. This matters for impact analysis: a single node failure in a properly configured cluster shouldn't take down the service. Without this CI, you can't model that resilience. Every node looks independent, and your impact maps overstate the blast radius.
cmdb_ci_storage_cluster_node
The membership record — it represents an individual storage system's participation in a cluster. Each node points back to the cmdb_ci_storage_cluster it belongs to via a relationship (typically Member of), and each node corresponds to a cmdb_ci_storage_server.
This exists as a separate class rather than just a relationship because nodes carry cluster-specific state: active/passive role, failover priority, replication role (source vs. destination), quorum vote status. A storage server's attributes describe the hardware. The cluster node's attributes describe how that hardware behaves within the cluster context.
In a two-node MetroCluster you'd have one cmdb_ci_storage_cluster, two cmdb_ci_storage_cluster_node records, and two cmdb_ci_storage_server records.
cmdb_ci_storage_volume
The logical unit of storage that gets presented to consumers — a LUN, a volume, a vDisk, or a file share, depending on protocol and vendor terminology. This is where block storage gets carved from a cmdb_ci_storage_container (pool or aggregate) and mapped to a host or cluster.
Key attributes include capacity (allocated vs. used), protocol (FC, iSCSI, NFS, SMB), thin provisioning status, snapshot policy, and the host mapping (which server or HBA WWN can access it).
This is arguably the most relationship-rich CI in the storage model. It relates upward to the container it's carved from, sideways to the storage server that presents it, and outward to every cmdb_ci_server, VMware datastore, or Kubernetes PVC that consumes it.
cmdb_ci_storage_controller
The physical controller module inside a storage server — the board with the CPU, cache memory, and host-facing ports that actually processes I/O. Most enterprise arrays are dual-controller (controller A and controller B in active-active or active-passive).
This class exists because controllers fail independently from the chassis. If controller A fails, the array may still serve I/O through controller B — but at degraded performance. Without modeling controllers as separate CIs, you can't represent that partial failure scenario in your CMDB.
Key attributes include controller position/slot, cache size, firmware version, operational status, and the FC/iSCSI/NVMe-oF ports attached to it. It relates to cmdb_ci_storage_server via Contained by and to specific cmdb_ci_storage_volume records via path/ownership relationships (which controller currently owns which volumes).
How the classes chain together
The relationship hierarchy in a typical SAN discovery looks like this:
|
TYPICAL SAN DISCOVERY CHAIN cmdb_ci_storage_server (the array) → contains cmdb_ci_storage_enclosure (the shelves) → contains cmdb_ci_storage_disk (the drives) → grouped into cmdb_ci_storage_container (pools/aggregates) → which serve cmdb_ci_storage_volume (LUNs presented to hosts) |
Cluster constructs sit alongside this chain. Multiple storage servers can participate in a single cmdb_ci_storage_cluster via their cmdb_ci_storage_cluster_node records, and cmdb_ci_storage_controller records sit inside each storage server, owning specific volumes.
Common mistakes to avoid
Treating cmdb_ci_disk and cmdb_ci_storage_disk as interchangeable
This is the most common mistake. If you're building CIs manually or via integration, always use cmdb_ci_storage_disk for array-managed drives so the relationship chain to pools and volumes stays intact. Use cmdb_ci_disk only for server-local drives — boot disks, local RAID in compute nodes.
Skipping cmdb_ci_storage_container
Teams often jump straight from array to volumes. Without the pool/aggregate layer you lose capacity planning visibility — you can't answer "how full is this aggregate" or "which pool is over-provisioned" without it.
Letting Discovery do its job — or modeling the full chain by hand
If Discovery (Storage Management patterns via ServiceNow, or third-party tools like Device42 or Nlyte) is doing the population, these classes and relationships will hydrate automatically. If you're building a custom integration or import set, model the full chain — or you'll regret it the first time someone asks for an impact analysis on a failed enclosure.
Storage model hierarchy
The two diagrams below show what a fully populated storage model looks like in CMDB. The first is a service map view of a real NetApp discovery, with the storage server at the center and its related CIs fanning out. The second is the abstract relationship model — the classes themselves and how they relate, independent of any specific vendor.
Service map view: a populated NetApp model
Figure 1. Service map view of a NetApp storage server, showing storage volumes, network adapters, the storage cluster, a cluster node, controllers, a chassis, a storage pool, and the disks beneath it.
Class relationship model
Figure 2. The CMDB class relationship model. The storage server is the anchor. Volumes, pools, clusters, controllers, network adapters, FC and iSCSI exports, and cluster nodes all connect to it through specific named relationships.
Summary
Storage classes in CMDB look similar on the surface and behave very differently in practice. Choosing the right class for each piece of the model is the difference between a CMDB that answers operational questions and one that quietly misleads. The pattern to internalize:
- cmdb_ci_disk is for server-local drives. cmdb_ci_storage_disk is for array-managed drives.
- cmdb_ci_storage_pool is the RAID-group layer. cmdb_ci_storage_container is the aggregate or tier above it.
- cmdb_ci_storage_cluster plus cmdb_ci_storage_cluster_node lets you model HA correctly so impact analysis reflects real resilience.
- cmdb_ci_storage_controller lets you represent partial-failure scenarios that the storage server CI alone can't capture.
Note: This level of detail will eventually be accessible within the Data Model Navigator.