Rack Elevation Diagrams

Back to Data Center Management · Asset Tagging · Cable and Port Documentation · CMDB · Service Offerings

A rack elevation is a visual map of what occupies every rack unit, kept current as hardware moves. One diagram per rack, drawn to the U, showing what is installed, what is empty, and what is reserved.

Its value is that it answers physical questions without anyone walking to the room — and the physical questions are the ones that stop an installation dead. Not "is there space", which people answer optimistically from memory, but "is there space of the right height, at the right depth, within the weight limit, with power of the right type on both feeds."

1. Front and Rear Are Two Different Diagrams

A front-only elevation is the most common version and it is incomplete, because a significant part of a rack lives at the back: vertical PDUs, cable managers, rear-mounted patch panels, and the power and network connections of everything mounted from the front.

• The front view shows what you see when looking for a machine — faces, bezels, drive bays, status lights, and which units are empty.
• The rear view shows what you work on — PDU positions and outlet numbering, which device is on the A feed and which on the B, cable paths, and anything rear-mounted that the front view cannot show at all.

The rear view is also where power feed diversity becomes visible. Dual-PSU hardware with both cords in the same PDU is a single point of failure that looks perfectly fine from the front, and is obvious the moment the rear elevation is drawn honestly.

2. What Each Unit Entry Carries

3. The Physics the Diagram Enforces

• Weight, bottom-heavy. Racks have a static load rating and so does the floor beneath them, and a top-heavy rack is a tipping risk when it is on castors or being worked on. Heavy chassis go low. The elevation makes the distribution visible at a glance in a way a spreadsheet does not.
• Airflow, front to back. Equipment draws cold from the front aisle and exhausts hot to the rear. Every empty U needs a blanking panel, otherwise hot exhaust recirculates through the gap to the intake side and the machines around it run hotter for no reason. An elevation that marks empty units is also a list of where blanking panels are missing — which is why the diagram above shows them explicitly.
• Depth and the rear door. Deep chassis plus cable bend radius can mean the rear door no longer closes, which matters a great deal in a contained-aisle room.
• Circuit headroom. The sum of the rack's draw against the circuit rating, with the derating your local code requires. This is the arithmetic behind capacity planning at the physical layer.

4. Reserved Is a State, Not a Note

Space allocated to a project that has not arrived yet must appear on the diagram as reserved. Without it, two people plan into the same four units six weeks apart and discover the collision on install day, with hardware already on site.

The same applies in reverse: hardware that has been decommissioned but is still physically racked is not free space, and marking it as such is how it eventually gets pulled rather than sitting powered off for a year.

5. It Should Be a View, Not a Drawing

The failure mode of rack elevations is specific and nearly universal: someone produces a careful diagram, it is accurate for a month, and then hardware moves and the file does not. Two years later it is a historical document that still looks authoritative.

The fix is structural. The elevation should be rendered from the inventory, not maintained beside it. When location is a field on the asset record, the diagram is a view of that field and cannot drift independently — updating the record updates the drawing, and there is only one thing to keep true.

• Purpose-built tooling — NetBox, RackTables, Device42 and similar model racks natively and render elevations from the data. NetBox in particular is widely used and open source.
• A spreadsheet is a legitimate starting point for a handful of racks, provided it is the single source and the diagram is generated from it rather than drawn alongside it.
• A hand-drawn diagram maintained separately is the one arrangement to avoid, however good it looks on the day it is produced.

6. Where It Earns Its Keep

• Directing remote hands. "Rack B12, front, the 2U unit at U14 to U15, third drive from the left" is unambiguous to someone who has never seen your estate. This is the single biggest practical return, particularly in a colocation facility.
• Planning an install before ordering. Height, depth, weight and power checked on paper, which is where you want to discover a problem.
• Incident response. Finding the right machine quickly, and knowing what else shares its circuit before you pull anything.
• Audits and insurance. A current elevation is straightforward evidence of physical control over the estate.
• Moves and migrations. The before-and-after of a rack consolidation is two elevations, and the plan is the diff between them.

How We Approach It

1. Survey each rack front and rear, recording position, height, depth, weight and power connection per device — and the PDUs and patch panels, which are usually absent from whatever exists already.
2. Reconcile against the asset register. The discrepancies found here are typically the most valuable output of the whole exercise.
3. Put the data where it can be rendered from, so the elevation is a view rather than a second artefact.
4. Add the derived checks — total weight against rating, draw against circuit, free U, missing blanking panels.
5. Mark reserved space for anything already committed.
6. Tie updates to the change process, the same way as for asset records, so accuracy does not depend on anyone remembering.

What You Get

• Front and rear elevations for every rack, drawn to the U, including PDUs and patch panels.
• Per-rack totals for weight, power draw and free units, each against its limit.
• A list of empty units missing blanking panels, and of dual-PSU hardware that is not genuinely on two feeds.
• Reserved space recorded as reserved, so two projects cannot plan into the same units.
• The elevations generated from the inventory, with the update step inside your change process.

A rack elevation is cheap to produce and cheap to keep current if it is a view of data you already maintain. It is only expensive when it is a drawing somebody has to remember to redraw — which is also the version that is wrong when you need it.