You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been centralizing around Netbox for IPAM/DCIM and inventory in my datacenter for awhile. While the network and device tracking side of things seems pretty well complete, I have found myself constrained by the current model for tracking power.
Our use case is branch circuit monitoring in a combined colocation/cloud facility. Netbox is where we track customer IP assignments, as well as customer power feed assignments to the cabinet's CDU (we stop tracking stuff there for colo, of course).
We have a collectd/modbus setup that hooks up to the branch circuit monitoring system inside of our big PDUs. I hook into Netbox's graphql API and join customer data with channel data from the power usage database.
Here's where I feel constrained by each model:
Power Panels
In a typical datacenter, power is fed into a PDU. This is a standalone device that takes up several floor tiles worth of space. The PDU has several power "panels", and this is the first spot I feel constrained in.
These PDUs are also responsible for feeding "subpanels" inside of RPPs (remote power points). Those RPPs also contain several breaker panels that can feed cabinets with power. Our RPPs are fed by multiple PDUs for redundant power as well.
I currently find myself using custom fields to identify which PDU each panel belongs to. Before that, we were having to consistently name each panel and use a string split in our query for usage. So I end up with these verbosely named panels. And in a large high power, and redundant power facility (hospital grade) this gets out hand and make it hard to stay consistent as infrastructure changes.
Power Feeds
This is the model that I feel most constrained by, and there are several things I think could be modeled more closely to the real world. I treat a power feed as a breaker in a panel, and there are several nuances about electricity, especially differences between America/Europe that could be modeled a little differently.
The first part of the model that could be elaborated is the phase selection. And this extends out to the Power Outlet model's leg selection as well. I think Three Phase / Single Phase is a bit misleading / constraining in some cases. In our case, we haven't been able to effectively model how power in our datacenter is actually being used!
In our facility, while most of our breakers are 3 leg supply, the other portion are two leg breakers. The reason for 2 pole breakers, is so that we can delivery "single phase" 208V power to the end device/ 208 volts is achieved by going from Phase A to Phase B, where as typically you would see Phase A to an (unbreakered) neutral (this only delivers 120 Volts).
The case is the same with the 3 pole breakers. The poles are connected in 3 enumerated pairs of 2 poles by the cabinet CDU. This results in 3 "banks" of power, AB, BC, AC legs connected. The resulting power delivered to the server is "single phase" 208v. The source legs are determined by which bank the device is plugged into.
Driven by a need to have a record of which leg (the CKT) is child to in each feed, I've had to adopt custom fields and this nomenclature for the feeds. While it works, it's still messy and the "single phase" field is not pedanticly accurate. A pole count number or list option of circuit numbers would resolve a lot of issues here.
With a list of circuit numbers, I would expect that flows into the "feed leg" option of the power outlet model as well, so that we can model our banks.
Power Outlet
The most useful thing for me here, which depends on the circuit number list, would be to allow the "feed leg" to be a multi-select, whereas now it is not. We use the A/B/C more as a "bank number" than a mapping to the actual leg. And this requires additional metadata to be created externally, before we can truly map our power flow from utility to device.
If the multiselect existed, I would be able to determine the effective voltage of an outlet and what phases are actually in use, where as now I've had to rely on hardcoded voltage values and external data.
I'd be interested to see if anyone has a similar use case or has thought similarly that there is room for elaboration within the scope of Netbox itself regarding the power models. Furthermore, I"m open to criticism if I seem to be over complicating this, as the electrical world does fall on the edge of my domain expertise.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I've been centralizing around Netbox for IPAM/DCIM and inventory in my datacenter for awhile. While the network and device tracking side of things seems pretty well complete, I have found myself constrained by the current model for tracking power.
Our use case is branch circuit monitoring in a combined colocation/cloud facility. Netbox is where we track customer IP assignments, as well as customer power feed assignments to the cabinet's CDU (we stop tracking stuff there for colo, of course).
We have a collectd/modbus setup that hooks up to the branch circuit monitoring system inside of our big PDUs. I hook into Netbox's graphql API and join customer data with channel data from the power usage database.
Here's where I feel constrained by each model:
Power Panels
In a typical datacenter, power is fed into a PDU. This is a standalone device that takes up several floor tiles worth of space. The PDU has several power "panels", and this is the first spot I feel constrained in.
These PDUs are also responsible for feeding "subpanels" inside of RPPs (remote power points). Those RPPs also contain several breaker panels that can feed cabinets with power. Our RPPs are fed by multiple PDUs for redundant power as well.
I currently find myself using custom fields to identify which PDU each panel belongs to. Before that, we were having to consistently name each panel and use a string split in our query for usage. So I end up with these verbosely named panels. And in a large high power, and redundant power facility (hospital grade) this gets out hand and make it hard to stay consistent as infrastructure changes.
Power Feeds
This is the model that I feel most constrained by, and there are several things I think could be modeled more closely to the real world. I treat a power feed as a breaker in a panel, and there are several nuances about electricity, especially differences between America/Europe that could be modeled a little differently.
The first part of the model that could be elaborated is the phase selection. And this extends out to the Power Outlet model's leg selection as well. I think Three Phase / Single Phase is a bit misleading / constraining in some cases. In our case, we haven't been able to effectively model how power in our datacenter is actually being used!
In our facility, while most of our breakers are 3 leg supply, the other portion are two leg breakers. The reason for 2 pole breakers, is so that we can delivery "single phase" 208V power to the end device/ 208 volts is achieved by going from Phase A to Phase B, where as typically you would see Phase A to an (unbreakered) neutral (this only delivers 120 Volts).
The case is the same with the 3 pole breakers. The poles are connected in 3 enumerated pairs of 2 poles by the cabinet CDU. This results in 3 "banks" of power, AB, BC, AC legs connected. The resulting power delivered to the server is "single phase" 208v. The source legs are determined by which bank the device is plugged into.
Driven by a need to have a record of which leg (the CKT) is child to in each feed, I've had to adopt custom fields and this nomenclature for the feeds. While it works, it's still messy and the "single phase" field is not pedanticly accurate. A pole count number or list option of circuit numbers would resolve a lot of issues here.
With a list of circuit numbers, I would expect that flows into the "feed leg" option of the power outlet model as well, so that we can model our banks.
Power Outlet
The most useful thing for me here, which depends on the circuit number list, would be to allow the "feed leg" to be a multi-select, whereas now it is not. We use the A/B/C more as a "bank number" than a mapping to the actual leg. And this requires additional metadata to be created externally, before we can truly map our power flow from utility to device.
If the multiselect existed, I would be able to determine the effective voltage of an outlet and what phases are actually in use, where as now I've had to rely on hardcoded voltage values and external data.
I'd be interested to see if anyone has a similar use case or has thought similarly that there is room for elaboration within the scope of Netbox itself regarding the power models. Furthermore, I"m open to criticism if I seem to be over complicating this, as the electrical world does fall on the edge of my domain expertise.
Beta Was this translation helpful? Give feedback.
All reactions