How to model data center power for impact analysis
How to model panels, feeds, PDUs and A/B redundancy in a DCIM so that you know what loses power before you switch off a breaker.
A feed trips at 3 a.m. The on-call engineer is paged for a rack that only half responds: some hosts are up, some are gone, and the monitoring dashboard is full of alerts that keep flapping as machines reboot. The first question is what has just lost power, and nobody can answer it without walking the aisle with a flashlight.
Power documentation exists to prevent that situation. Most teams document network cabling carefully and then keep power in a spreadsheet, or only in people's heads. Power is connectivity as well: a power connection has two ends, a path and a capacity. If your DCIM models it that way, you can answer "what depends on this feed" with a query.
The objects to model
Good data center power management starts with the physical objects themselves:
- Power panels are the distribution boards that split utility or UPS output into individual circuits.
- Power feeds are specific circuits from a panel, each with a voltage, phase and amperage rating. The feed is the unit of capacity and the unit of failure.
- PDUs are the rack power distribution units that take a feed and split it into outlets.
- Power ports and outlets are the connection points on devices and PDUs.
A feed has to be more than a label on a PDU. It is an object in the model with a rating, it comes from a panel and it supplies a piece of equipment. Once the panel, the feed and the PDU are all objects in the model, the software can follow the chain from the utility to the server.
Model both ends of the power cable
Power documentation often fails at one point. Many tools let you record "this PDU is fed by circuit 14" as a free-text note and "this server draws 300W" as a field, but they do not connect the two.
Danbyte treats a power connection as a cable with both ends in the model, in the same way as network cabling. A PDU outlet connects to a device's power port, and that connection is an object of its own.
Everything later in this post depends on that. Because both ends exist, the model can follow the path:
Panel A ──► Feed A-14 (208V, 20A) ──► PDU-A ──► outlet 7 ──► server power port 1
Panel B ──► Feed B-09 (208V, 20A) ──► PDU-B ──► outlet 7 ──► server power port 2
That server is dual-fed. Both cords are documented, and each one traces back through a different PDU to a different feed on a different panel. The single-corded server in the next rack has only the first line. The difference is recorded in the model, so nobody has to remember it.
Checking A/B redundancy
"Everything critical is dual-fed" is a claim that tends to be true until something changes. Someone racks a new appliance with a single power supply. Someone connects both cords of a "redundant" pair to the same PDU during a rushed install. Someone decommissions the feed to PDU-B and does not notice the four servers that are now single-corded.
When both ends of every power cable are modeled, you can check redundancy:
- A device is A+B redundant only if its power ports trace back to two independent feeds, ideally on separate panels.
- Two cords on the same PDU do not give redundancy. That PDU is a single point of failure, and tracing the two power ports shows it.
- Single-corded devices in a row that is meant to be redundant can be found before a failure finds them.
In Danbyte you check a device by tracing each of its power ports. The trace follows the cable through the PDU to the feed. This is the practical use of PDU modeling: a statement you can verify about where each outlet's power comes from, and whether the other side stays up when one side is lost.
Capacity against the feed rating
Every feed has a rating, and every device connected to it has a draw. Because the connections are modeled, the load can be added up and compared with the rating. Danbyte does this for each rack. The demand is the draw recorded on the power ports of the devices in the rack, and the supply is what the rack's primary feeds can deliver.
That gives you rack power capacity as a figure that is always current, where otherwise you would work it out once a quarter:
- You can see how much of the supply is already committed before you rack the next device.
- You can find racks that are oversubscribed on paper, and racks where losing the B side would load the A side beyond its rating. Danbyte counts a rack's primary feeds as its supply, and where it works from PDU ratings it takes the smaller of the A and B sides, because either side has to be able to carry the rack alone.
- You can plan growth against the recorded headroom, without guessing what the row can take.
These figures come from the draws you record. Danbyte does not meter the feed.
The redundancy question and the capacity question are closely related. Both come down to whether the remaining side has room to carry the load when you lose the other one.
Finding what depends on a feed
Power impact analysis uses the graph you have already built.
Before you switch off Feed A-14 for maintenance, ask the model what depends on it. In Danbyte the feed's Terminations tab lists the cables that land on the feed, which is usually the inlet of the PDU it powers. The feed's Affected tab lists:
- The racks the feed delivers to.
- The devices in those racks.
- For each rack and device, whether the result is an Outage, because nothing else feeds the rack, or Reduced redundancy, because another feed still does.
Danbyte makes that classification per rack. A single-corded device in a rack that has a second feed is therefore listed as reduced redundancy, even though it may lose power, so trace the power ports of any device you are unsure about.
With that list, the maintenance window is a planned decision. The dual-fed servers keep running on their B side. The three single-corded servers get a warning or a temporary cord before you touch the breaker. When a feed trips by itself at 3 a.m., the same list answers the opposite question: it shows what lost power and what should have stayed up. A device that should have stayed up and did not is usually where the underlying fault is.
Power modeling in Danbyte
Danbyte models panels, feeds, PDUs and power cables as objects, so redundancy, capacity and impact analysis use the same graph that documents your network. You can self-host it. The features page gives an overview, and the docs explain how to add your first panel and feed.
