Nut upsuser - Oct 2015 - Can this be done with NUT? (ordered shutdown, revisited)

Good morning everyone,

we're currently in the process of redesigning our UPS signalling scheme,
and decided to have a closer look at NUT.

This is our setup:
- a (really) big UPS (Piller, with a web/SNMP interface)
- several computer rooms with equipment of different importance,
  managed by several people not sharing ssh keys etc., with an
  unknown number of machines
- IPMI signalling to forcibly kill, or wakeup individual machines

Our goal is to:
- provide a single point of information (ideally, a laptop that can
  continue running on its own battery)
- let clients decide whether "their" power supply can still be 
  considered trustworthy
- have different "low battery" conditions (charge levels) for groups 
  of computers, hoping that reduced load would give other, more
  essential services, a longer runtime
- NOT base shutdowns on timers (because changing loads will also change
  the discharging curve)

What I currently tried:
- I found a longish discussion on this list, dating back to six years
  ago:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2009-February/004772.html
  In particular, Marco's requirements look quite similar to ours, but
  there was apparently no solution (back then). I mayhave missed a later
  continuation though.
- Use multiple drivers, with override.battery.charge.low set to various
  levels - or "dummy-ups" repeaters with the same modification
- Let client groups upsmon-read one of those "virtual" UPSes

What I found:
- upsd obviously doesn't calculate LB itself (even if charge.low is set
  to 105.00 for testing purposes). Does this only happen on OB, or does
  upsd do no calculations at all?
  Apparently, ordered handling of multiple shutdown conditions cannot be
  done this way?

Is there still a way to provide, at a single central point, multiple 
UPS conditions that can be used by multiple upsmon client processes?
There is a simple reason why I don't want to do excessive upssched etc.
work on each individual client when a single bit of information should
suffice. There is no general way to reach a client from the UPS manager
machine (as in ssh, telnet, etc.), just the UPSD port.

Or should I look for something else (recommendations off-list)?

Thanks,
 Steffen

-- 
Steffen Grunewald, Cluster Administrator
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Am M?hlenberg 1
D-14476 Potsdam-Golm
Germany
~~~
Fon: +49-331-567 7274
Fax: +49-331-567 7298
Mail: steffen.grunewald(at)aei.mpg.de
~~~

On Oct 6, 2015, at 5:40 AM, Steffen Grunewald <Steffen.Grunewald at
aei.mpg.de> wrote:
> 
> What I currently tried:
> - I found a longish discussion on this list, dating back to six years
>  ago:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2009-February/004772.html
>  In particular, Marco's requirements look quite similar to ours, but
>  there was apparently no solution (back then). I mayhave missed a later
>  continuation though.
Right, I don't think the "ignorelb" flag was added to drivers
until 2011.
> - Use multiple drivers, with override.battery.charge.low set to various
>  levels - or "dummy-ups" repeaters with the same modification
> - Let client groups upsmon-read one of those "virtual" UPSes
> 
> What I found:
> - upsd obviously doesn't calculate LB itself (even if charge.low is set
>  to 105.00 for testing purposes). Does this only happen on OB, or does
>  upsd do no calculations at all?
>  Apparently, ordered handling of multiple shutdown conditions cannot be
>  done this way?
Also correct that upsd does not calculate LB, but the drivers can do what you
are describing if the "ignorelb" flag is set. Using dummy-ups in
repeater mode does sound like a good option.

Another potential hitch: while you can override LB, I haven't looked into
overriding OB. So for testing, it might be necessary to have a copy of dummy ups
reading from a file, in place of the actual snmp-ups driver.

-- 
Charles Lepple
clepple at gmail

Hi Charles, all:

On Tue, Oct 06, 2015 at 08:45:40AM -0400, Charles Lepple
wrote:
> On Oct 6, 2015, at 5:40 AM, Steffen Grunewald <Steffen.Grunewald at
aei.mpg.de> wrote:
> > 
> > What I currently tried:
> > - I found a longish discussion on this list, dating back to six years
> >  ago:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2009-February/004772.html
> >  In particular, Marco's requirements look quite similar to ours,
but
> >  there was apparently no solution (back then). I mayhave missed a
later
> >  continuation though.
> 
> Right, I don't think the "ignorelb" flag was added to drivers
until 2011.
And somehow this option is named in a way that made my input filter drop it
quite early. 
Yes, indeed, this one does the trick.
I still don't understand where exactly it happens :/ (but I don't care
much)
> > - Use multiple drivers, with override.battery.charge.low set to
various
> >  levels - or "dummy-ups" repeaters with the same
modification
> > - Let client groups upsmon-read one of those "virtual" UPSes
> > 
> > What I found:
> > - upsd obviously doesn't calculate LB itself (even if charge.low
is set
> >  to 105.00 for testing purposes). Does this only happen on OB, or does
> >  upsd do no calculations at all?
> >  Apparently, ordered handling of multiple shutdown conditions cannot
be
> >  done this way?
> 
> Also correct that upsd does not calculate LB, but the drivers can do what
you are describing if the "ignorelb" flag is set. Using dummy-ups in
repeater mode does sound like a good option.
It is ;)

What I am doing now:

- have a (primary) snmp-ups driver with override.battery.charge.low = 50 *and*
  ignorelb = true (is this correct syntax?), as 50% is the critical capacity
  where I cannot trust the UPS anymore (for more than a few minutes).
  battery.runtime returns random numbers, batttery.runtime.low is 0, and I
  don't have a better guess either :/

- a bunch of dummy-ups drivers, each with a different charge.low setting (55,
  60, 70, 85, 105 [!]), and ignorelb set.
> Another potential hitch: while you can override LB, I haven't looked
into overriding OB. So for testing, it might be necessary to have a copy of
dummy ups reading from a file, in place of the actual snmp-ups driver.
This is easy: just insert a "override.battery.charge = 66.66" into the
primary
driver definition while testing - which can be done with
  upsc -l | xargs -t -i% upsc %$localhost ups.status
When done with testing, "upsdrvctl stop primary", remove the override
from ups.conf
and "upsdrvctl start primary". 

Yes, you'll get "OL LB" reports. Don't know what an upsmon
would do with that :)
(Workaround: Next to override.battery.charge, define override.ups.status?)


There's only one drawback caused by the repeater logic set up this way:

- upsdrvctl will start the primary (real) driver since it can connect via snmp

- upsdrvctl fails (Connection refused) connecting to the repeaters since upsd
  isn't running yet

- upsd will only see the primary driver (can't connect to ... dummy-ups) 
  but then provide a path for the repeaters which will be started by a second
  invocation of "upsdrvctl start"

- everything is fine after that

Just using "/etc/init.d/nut-server start" will fail: it will fire up
the
primary driver and upsd, but not the repeaters. I presume a "upsdrvctl
start"
(in /etc/rc.local?) will handle this. (OS is Debian Wheezy.)

This is fine with me as "repeaters" were probably invented to be run
on a
machine different from the one running the primary driver(s), and therefore
connecting to an already running upsd is the "typical use case".

Thanks a lot, Charles, you saved my week!

Steffen

-- 
Steffen Grunewald, Cluster Administrator
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Am M?hlenberg 1
D-14476 Potsdam-Golm
Germany
~~~
Fon: +49-331-567 7274
Fax: +49-331-567 7298
Mail: steffen.grunewald(at)aei.mpg.de
~~~