How to Prove A/B Power Redundancy in Practice

Two power cords are a design intent, not a proof. The intent becomes real only when each cord reaches a different feed, each feed comes from a different panel, and each panel is supplied by a different upstream source. Any shared link in that chain collapses the two paths into one failure domain, and the server keeps running on two power supplies that both depend on the same breaker.

The proof is a records exercise before it is a drill. You need the rack summary, the device power summary, the feed connections, and the upstream source links for each panel. Obelinf exposes all four, and the interesting part is not the happy path. It is the false positive that appears when two panels have no documented source link, or the degraded result that appears when two panels share a UPS. This procedure runs the checks, interprets the output, and tells you what to fix before you schedule a live test.

What A/B redundancy actually requires

A/B redundancy starts with two independent sources and ends with two independent device inlets. The full condition is stricter than most rack diagrams suggest:

• Each side has its own upstream source, or a source path that does not share a single point of failure.
• Each side has its own panel and breaker.
• Each side has its own feed, with a documented breaker position.
• Each feed lands on a different device inlet.
• Each side can carry the full rack load during the failure of the other.

The last condition is the one that changes the budget. If each feed can deliver 5 kW, the rack budget is 5 kW, not 10 kW. The A and B capacities are not additive. They are two attempts at the same requirement, and the requirement is that either one survives alone.

The model uses failure domains to represent this. Two feeds on the same panel are one domain. Two panels fed by the same source are one domain. Two panels with no documented source are treated as separate panel domains, which is useful for inventory but dangerous for redundancy claims. That is why the proof has to include the source links, not just the device summary.

Start with the rack summary

Find the rack ID first, then read the rack power summary. The summary returns the rack load, the feed capacity, the redundant capacity, the panel count, the failure domain count, and the individual feeds with their breaker positions and loads.

export OBELINF_API_KEY="your_read_write_key"
export OBELINF_ORG="acme-netops"
export API="https://api.obelinf.com/${OBELINF_ORG}"

curl --fail --silent --show-error \
  -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  "${API}/racks?q=R07" \
  | jq -r '.racks[] | [.id, .name, .site_name] | @tsv'

Save the returned id as RACK_ID.

curl --fail --silent --show-error \
  -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  "${API}/power/summary/rack/${RACK_ID}" \
  | jq '{
      rack_name,
      load_w,
      device_count,
      feed_capacity_w,
      redundant_capacity_w,
      redundancy,
      panel_count,
      failure_domain_count,
      utilization_pct,
      feeds: [.feeds[] | {
        id,
        name,
        panel_id,
        panel_name,
        breaker_position,
        role,
        capacity_w,
        load_w
      }]
    }'

Read four values before anything else. panel_count tells you whether the feeds reach more than one panel. failure_domain_count tells you whether those panels resolve to distinct upstream sources. redundancy is n+1 when more than one domain exists and none otherwise. redundant_capacity_w is the capacity that remains after the largest failure domain is removed, which is the number to compare with the rack load.

Do not use feed_capacity_w as the rack budget. It is the sum of the active feeds, and in an A/B rack that sum includes both sides. The useful budget is redundant_capacity_w, because it survives the loss of the largest domain. If the rack load is above that value, the surviving side cannot carry the rack after a failure.

Read each feed against its capacity

The feed list inside the rack summary is the evidence for each side. Pull the name, panel ID and name, breaker position, role, capacity, and load into a fixed shape so two racks can be compared without rereading the JSON.

curl --fail --silent --show-error \
  -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  "${API}/power/summary/rack/${RACK_ID}" \
  | jq -r '.feeds[]
      | [.name,
         .role,
         .panel_id,
         .panel_name,
         (.breaker_position // "NO BREAKER"),
         (.capacity_w // 0),
         (.load_w // 0),
         (if .capacity_w then ((.load_w / .capacity_w) * 100 | floor) else "unrated" end)]
      | @tsv'

A healthy A/B rack shows two rows with different panels and breaker positions, both with a capacity above the rack load. A row with NO BREAKER is a documentation gap. A row with the same panel as its partner is a shared failure domain. A row with no capacity is a feed whose voltage or amperage is missing, which means the capacity calculation cannot protect you.

The feed load is a routing view, not the rack budget. It can be calculated from the connected device inlet or, when no cable endpoint exists, from the rack devices. That fallback is useful for a quick estimate, but it means feed loads should not be added together to prove redundancy. Use the rack load and the redundant capacity for the final number, and use the feed rows to prove that the paths are separate.

Read the device power summary

The rack summary proves the rack has two paths. The device summary proves the device is actually attached to both. List the devices in the rack, then read the power summary for each dual corded device.

curl --fail --silent --show-error \
  -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  "${API}/devices?rack_id=${RACK_ID}&limit=100" \
  | jq -r '.devices[] | [.id, .name] | @tsv'

Save the device id as DEVICE_ID. Then read the power summary for that device.

curl --fail --silent --show-error \
  -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  "${API}/power/devices/${DEVICE_ID}/power" \
  | jq '{
      device_name,
      redundancy,
      feed_count,
      panel_count,
      failure_domain_count,
      inlets: [.inlets[] | {
        name,
        connected_to,
        upstream_feed
      }]
    }'

The summary returns one of four redundancy values. unconnected means there are no inlets. single means one inlet, which is a single path no matter how many power supplies the chassis has. degraded means more than one inlet but not enough separation in the panels or failure domains. redundant means more than one inlet, more than one panel, and more than one documented failure domain.

The inlet rows are the part to keep. Each inlet shows the connected endpoint and the upstream feed, including the panel and feed role. If inlet A and inlet B both point to feeds on the same panel, the device is degraded. If they point to different panels that both resolve to the same source, the device is also degraded. If one inlet has no connection, the second path is not real yet.

Check the panels upstream

The device summary depends on the source links attached to each panel. Read the panel detail for every panel in the rack and confirm that it has at least one active source link. Use each panel_id from the rack summary as PANEL_ID. A panel with no source link is a panel with an unknown upstream path, even if it looks separate on the rack diagram.

curl --fail --silent --show-error \
  -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  "${API}/power/panels/${PANEL_ID}" \
  | jq '{
      panel: .power_panel.name,
      source_links: [.source_links[] | {
        upstream_source_name,
        role,
        is_active,
        priority
      }]
    }'

curl --fail --silent --show-error \
  -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  "${API}/power/panels/${PANEL_ID}" \
  | jq -e '.source_links | length > 0' >/dev/null \
  || echo "${PANEL_ID} has no documented upstream source"

A panel with two active source links is not automatically redundant. The two links may point to the same source through different paths, or to sources that share an upstream ATS. The link list is evidence, not a guarantee. Read the source names and compare them with the actual design before you accept the result.

A worked example

The rack summary can look healthy while the device summary tells a different story. The table below uses the same rack and three devices to show how the values change.

The first case is the one you want, but it still needs two checks that the counts cannot make. Confirm the sources are truly independent upstream, not two names on the same ATS. Confirm the breaker positions are different and match the panel schedule. The model can prove that distinct records exist; it cannot prove that the electrician wired them the way the records claim.

The last case is the false positive to watch for. Two unlinked panels are treated as separate panel domains, so the device summary can say redundant even when the upstream path is unknown. That does not make the data useless. It tells you which panels still need source links, and it prevents the summary from being worse than the documentation.

Test one side with a failure simulation

A simulation is a useful preflight before a real drill because it tests the model against the load. Pick the feed or source on one side, save its ID from the rack summary as FEED_A_ID, simulate its failure, and compare the affected devices and lost load with the device you expected to survive.

curl --fail --silent --show-error -X POST \
  -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  -H "Content-Type: application/json" \
  -d "{\"node_type\":\"feed\",\"node_id\":\"${FEED_A_ID}\"}" \
  "${API}/power/simulate" \
  | jq '{
      node_type,
      affected_feed_count,
      affected_devices: [.affected_devices[].name],
      affected_racks: [.affected_racks[].name],
      lost_load_w
    }'

The simulation uses the documented connections and source links. If a cable is missing, or a second inlet is unconnected, the result will be better than reality. Treat a clean simulation as a reason to verify the records, not as a reason to skip the physical check. A controlled drill that opens one breaker is still the only way to prove the wiring behaves as documented.

The A/B proof checklist

Use this list before you call a rack redundant:

• The rack has two active feeds with different panel IDs.
• Each feed has a breaker position and a rating that matches the panel schedule.
• Each panel has at least one active source link, and the sources are independent.
• Each feed has a real connected endpoint or a documented rack assignment.
• The dual corded device has two connected inlets, one on each feed.
• The rack load is below the redundant capacity, not the sum of both feeds.
• The simulation of one side leaves the intended devices running.
• The physical inspection matches the model, including breaker labels and outlet assignments.

Keep the proof current

A/B redundancy is a property of the current wiring, not a property of the original design. A server is replaced, a feed is moved, a panel is re fed, and the model still says redundant because nobody updated the connection. Put the proof on the same cadence as the power audit: quarterly for stable racks, before every deployment that adds a dual corded device, and after any breaker or panel change.

The review is short when the records are current. Read the rack summary, read the device summary, check the panel source links, and run the simulation for one side. If all four agree, the rack is documented. If they disagree, the disagreement is the worklist.

Start with one rack that matters and run the four commands in this article. The uncomfortable result is usually a device that everyone believed was redundant and a record that says otherwise. Finding that on a Tuesday afternoon is much cheaper than finding it during the first real power failure.

Obelinf provides the rack summary, device power summary, feed detail, and failure simulation as separate views of the same records, so the proof is a query rather than a reconstruction. That is the practical difference between having a redundancy design and being able to show it.