Maybe this will clear up what I was initially thinking.
In this diagram all lines on the right of the UPSs are power lines and all
lines on the left are serial/usb lines.
.---.
+--|UPS+-----+--------+--------+---...
| | A1| | | |
| '---' .---+--. .---+--. .---+--.
| |Server| |Server| |Server|
| | A1 | | A2 | | A3 |
| .---. '---+--' '---+--' '---+--'
| +|UPS| | | |
| || A2+-----+--------+--------+---...
| |'---'
| |
.-----+-+.
|Central |
|NUT Host|
'-----+-+'
| |
| |.---.
| +|UPS+-----+--------+--------+---...
| | B1| | | |
| '---' .---+--. .---+--. .---+--.
| |Server| |Server| |Server|
| | B1 | | B2 | | B3 |
| .---. '---+--' '---+--' '---+--'
| |UPS| | | |
+--| B2+-----+--------+--------+---...
'---'
My thinking was that this provides the following benefits:
1. When anyone needs to interface with the UPS Master there is no
ambiguity. There is only one.
2. All servers are slaves so any server can be dropped, rebooted or nuked
without affecting any other server.
3. (What I am not sure NUT can do) Each slave monitors either UPS group A
or B depending on what it drawing power from. If that group drops below
MINSUPPLIES then those slaves shut down.
That said the Central NUT Host would need to be able to survive any
combination of UPS outages.
Maybe instead I put a Raspberry Pi with one of these
http://www.seeedstudio.com/depot/lipo-rider-pro-p-992.html
on each UPS pair. Any thoughts on that solution?
Thanks again!
On Tue, Oct 14, 2014 at 8:56 PM, Charles Lepple <clepple at gmail.com>
wrote:
> On Oct 14, 2014, at 12:12 PM, Michael Stinaff <mstinaff at gmail.com>
wrote:
>
> I've used nut for simple configurations before but now one has grown to
a
> more complex setup and can't seem to find any info online.
>
> I would like to have single central nut master monitor a bank of UPSs for
> a whole rack of servers with redundant PSUs.
>
> So
> UPS A1 ---> Server group A PSU 1
> UPS A2 ---> Server group A PSU 2
>
> UPS B1 ---> Server group B PSU 1
> UPS B2 ---> Server group B PSU 2
>
> I've read numerous pages about using MINSUPPLIES for redundant
UPS->PSU
> setups, but nothing about setting up groups so that server bank B can stay
> up even if something happens to both UPS feeding server bank A.
>
> I've thought of a few possible solutions:
> 1. build a separate nut master for each group
> 2. use jails to make a lighter nut master instance for each group
> 3. run multiple instances of nut in the same server
>
>
> My gut reaction is to go with option 1, but I'm not sure I quite
> understand the other two options. In particular, for option 3, it is better
> to not treat NUT as a monolithic system, and to look at the processes which
> will be running.
>
> Let me make sure I understand your naming convention by building this up
> incrementally.
>
> If the first server only had one PSU, it would look like this:
>
> UPS A1 -> Server A-1 PSU 1 -> driver -> upsd -> upsmon
>
> If you expand that to both UPSes and PSUs for that one server, you would
> need two drivers, one upsd and one upsmon (probably with "MINSUPPLIES
1").
> You could start a second upsd, but it would need a second TCP port, and the
> separation wouldn't gain you much. upsmon is a client, and it does not
care
> whether all of the UPSes are hosted at the same upsd. With only one upsmon
> per upsd, each upsmon is in "master" mode - there are no slaves
yet.
>
> UPS A1 -> Server A-1 PSU 1 \
> > driver -> upsd -> upsmon
> UPS A2 -> Server A-1 PSU 2 /
>
> In this case, upsmon would monitor UPS_A1 at Server_A-1 and
> UPS_A2 at Server_A-1.
>
> Let's say you add a Server A-2 to the group. If you don't mind
ensuring
> that server A-1 is up all the time (e.g. if there are other critical
> processes already running on it), you could just make A-2 a slave to the
> upsd on A-1. (Trust me, my ASCII art skills are not up to that challenge.)
>
> Alternatively, you could add a bit of independence, and have UPS A1 be
> connected to a driver and upsd on server A-1, and have a mirrored setup
> with UPS A2 connected to a driver/upsd on server A-2. The upsmon processes
> would each connect to upsd at localhost, as well as the other server's
> upsd. This allows you to take either machine out of service, while still
> maintaining limited monitoring capability. With "MINSUPPLIES 1"
and one
> machine down, the second upsmon will assume the worst when the remote upsd
> disconnects it, and will shut down if the second UPS runs out of power.
>
> All of this is completely independent of server bank B. If you want to
> simply collect statistics across the A/B boundary, this should not pose a
> problem. However, consolidating the UPS monitoring on one side or the other
> will start to add dependencies, which makes it less likely that things will
> stay up as long as possible during a power outage. It's certainly
possible
> to put many of the monitoring processes on one side, but with modern
> servers, the stack of driver/upsd/upsmon is fairly lightweight compared to
> the rest of what is usually running on each server.
>
> Does this help? I feel like I am missing a critical detail about how you
> want to integrate the two server groups.
>
> --
> Charles Lepple
> clepple at gmail
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141015/b912fcf9/attachment.html>
On 2014-10-15 1:50 PM, Michael Stinaff wrote:> Maybe this will clear up what I was initially thinking. > In this diagram all lines on the right of the UPSs are power lines and all lines on the left are serial/usb lines. > > .---. > +--|UPS+-----+--------+--------+---... > | | A1| | | | > | '---' .---+--. .---+--. .---+--. > | |Server| |Server| |Server| > | | A1 | | A2 | | A3 | > | .---. '---+--' '---+--' '---+--' > | +|UPS| | | | > | || A2+-----+--------+--------+---... > | |'---' > | | > .-----+-+. > |Central | > |NUT Host| > '-----+-+' > | | > | |.---. > | +|UPS+-----+--------+--------+---... > | | B1| | | | > | '---' .---+--. .---+--. .---+--. > | |Server| |Server| |Server| > | | B1 | | B2 | | B3 | > | .---. '---+--' '---+--' '---+--' > | |UPS| | | | > +--| B2+-----+--------+--------+---... > '---'Mmmm... ASCII art.... So reminiscent of the 80's. Makes me wanna power up my BBS system and look at the old screens again. ;) I love it. (thumbs up) -Ben
On Oct 15, 2014, at 2:50 PM, Michael Stinaff <mstinaff at gmail.com> wrote:> My thinking was that this provides the following benefits: > 1. When anyone needs to interface with the UPS Master there is no ambiguity. There is only one.(See below)> 2. All servers are slaves so any server can be dropped, rebooted or nuked without affecting any other server.Agreed, although if you set things up for "MINSUPPLIES 1" and have one NUT upsd per UPS, e.g. UPS A1 with Server A1, and UPS A2 with Server A2, you can still take down one of A1 and A2 under good power conditions, and the rest of the servers will not shut down unless *both* A1 and A2 disappear or lose power.> 3. (What I am not sure NUT can do) Each slave monitors either UPS group A or B depending on what it drawing power from. If that group drops below MINSUPPLIES then those slaves shut down.It is easy to do set up the configuration files manually. Working from your diagram, the Central NUT Host exposes four UPSes: A1, A2, B1 and B2. Server A1 lists A1 at central and A2 at central in its upsmon.conf, and Server B1 lists B1 at central and B2 at central. What makes this potentially difficult is whether or not each UPS has a unique serial number exposed in its USB descriptors. If not, then you will run into problems telling the second, third and fourth drivers which UPS to talk to. USB bus numbers in Linux are not guaranteed stable across reboots, or especially kernel upgrades. That would make the Raspberry Pi solution a little more attractive. (Built-in serial ports do not typically suffer from this shifting name problem, but add-on PCI cards might.) One thing we will be rolling out soon is a library of upsc "dump files" that show a representative set of data from various UPS models. It's still on our CI server now, but this link should be good: http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/ddl/ Or check out the raw Git repository to grep for 'ups.serial': https://github.com/networkupstools/nut-ddl APC often includes serial numbers, as does MGE. Tripp Lite tends to include it on higher-end models, but beware of the serial numbers that start with "FW" and seem short - they look like they are firmware versions.> That said the Central NUT Host would need to be able to survive any combination of UPS outages.If it has enough redundant supplies, it should not be a problem. But then it becomes a single point of failure in terms of software and networking (bear in mind that the network gear between the central server and the slaves needs to be powered from an UPS as well).> Maybe instead I put a Raspberry Pi with one of these > http://www.seeedstudio.com/depot/lipo-rider-pro-p-992.html > on each UPS pair. Any thoughts on that solution?I would be interested to hear testing results with that hardware. I have been trying to do something similar with a NiMH power supply and a Raspberry Pi Model B, but it does not seem reliable under load: http://www.ghz.cc/charles/NUT/OpenElectrons_SmartUPS.html On the other hand, in my application, I am more concerned about shutting down the Pi cleanly, rather than keeping the network connections up. -- Charles Lepple clepple at gmail
On Oct 15, 2014, at 2:50 PM, Michael Stinaff <mstinaff at gmail.com> wrote:> 3. (What I am not sure NUT can do) Each slave monitors either UPS group A or B depending on what it drawing power from. If that group drops below MINSUPPLIES then those slaves shut down.I forgot to mention: the slave configuration is generally going to be manual, unless you segment the UPS output circuits and the networks in a similar fashion. I don't know of any PC power supplies that can get some sort of identification from the UPS that is directly feeding it, although this would be very handy for reducing errors in configurations such as this. If you had subnets that segregate the A and B groups, you might be able to do something with mDNS to find the nearest NUT master, but I don't know if I would depend on that unless servers move around frequently. -- Charles Lepple clepple at gmail
Just realized that I have ignored an important piece of info that actually
started me on this quest. Thank you for following me through the mud.
Hopefully this will clear a few things up.
Most if not all of the servers will be ESXi or FreeNAS boxes. FreeNAS has
nut built in and ESXi can have it added in with this great user created VIB
http://rene.margar.fr/2012/05/client-nut-pour-esxi-5-0/
However both can only monitor a single UPS.
So what I really need (but forgot I needed) is a way to create a virtual
UPS that groups two physical UPSes
Is this what I need? http://www.networkupstools.org/docs/man/dummy-ups.html
Is there a best practice or standard config for doing this?
Thank you and sorry for the wild goose chase!
No ascii diagrams this time. How about a squirrel?
,;;:;,
;;;;;
,:;;:; ,'=.
;:;:;' .=" ,'_\
':;:;,/ ,__:=@
';;:; =./)_
`"=\_ )_"`
``'"`
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141016/a092dedb/attachment.html>