It is night, an amber light is blinking on a server, and the vendor is on the way to replace a disk. The technician is in the server room looking for a machine they only know by hostname. Which aisle is it in? Which rack? Is it the one at the top or the one below it? And is it still covered by a support contract, or will the vendor arrive only to say this unit is no longer included?
Situations like this are not unusual. The physical layer is often the weakest part of IT records. The logical CMDB knows about applications and virtual servers, but it frequently says nothing about where hardware actually sits. The result is lost time at the worst possible moment, and needless uncertainty for the people who have to fix the problem.
Why physical records fall apart
Information about where hardware lives usually sits outside the main records. In practice we often see:
- separate spreadsheets with rack layouts, maintained by one person and updated by nobody else,
- floor plans stored as images or PDFs that stop being accurate after the first server move,
- support contracts in binders or a shared folder, with no link to specific pieces of hardware.
Each of these sources is useful on its own, but they are not connected. When a server moves to another rack, one spreadsheet changes and the others do not. When a contract expires, nobody is told that critical servers were still relying on it.
How to approach the physical layer
Location and contract coverage should be attributes of a CMDB item, just like the operating system or the owner. Then the logical and physical views share a single source of truth.
Good data center records follow a clear hierarchy: site, data center, room, aisle, rack and rack position. Every server, storage array and network device has its place in that hierarchy. Visualization builds on the structure, because someone standing in a server room needs a picture to orient themselves, not a table.
The link to support contracts matters just as much. For every piece of hardware you should be able to see which contract covers it, when it expires and what SLA the vendor guarantees. Only then can you decide quickly during an incident whom to call and what to expect.
How Eywo Stratum handles it
Eywo Stratum records data centers directly in the CMDB. The hierarchy covers site, data center, room, aisle, rack and rack position. Physical servers, storage, SAN and network devices carry their location as part of the item, with the same version history as every other attribute, so you can see who moved a server and when.
The room view shows how racks are laid out along the aisles. The rack view shows each position and what occupies it. Technicians see where to go, and capacity planners see where there is still space.
Hardware is linked to support contracts and vendors. For each item you can see which contract covers it, when that contract ends and which vendor SLA applies. An expiry overview shows where contracts are running out before it turns into a problem during a hardware failure. When an incident does occur, Eywo Stratum supports escalation to the vendor according to the support contract.
Because the physical layer lives in the same CMDB, it connects to the dependency map. You can trace a path from a rack all the way up to a business service. Before planned work in a server room, it is clear in advance which services could be affected.
Conclusion
A data center is more than a room full of machines. It is the layer everything else stands on. When it is captured in the CMDB as carefully as applications are, technicians find servers without searching, service owners know what carries their service, and nobody is surprised by a contract that ended a month ago.
Data center records and support contract management are included in the Business edition.
Eywo Stratum Business
For operations that want to connect monitoring, security and vendors.