[Nut-upsuser] UPS Groups?

[Michael Stinaff]

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>