[Nut-upsuser] sequence of events / timing upssched/master/slave etc

[Charles Lepple]

On Jan 28, 2008 9:28 AM, Olaf Zevenboom <olaf at artefact.nl> wrote:
> Charles Lepple wrote:
> > On Jan 25, 2008, at 10:39 AM, Olaf Zevenboom wrote:
> >
> >> Dear List,
> >>
> >> I am a bit uncertain about some aspects of NUT and have not been able to
> >> find the desired info in the documentation.
> >> We have a server monitoring the network and it is also running the
> >> ups/nut-daemon. Together with some other important servers (all Linux)
> >> it is logical to make these monitor the UPS as 'master'. While other
> >> servers (mostly windows running winnut, some linux) can be configured to
> >> monitor the ups daemon as slaves.
> >> The server running the daemon is configured to use upssched.
> >> The questions are:
> >> - flags/events : are these broadcasted to other servers so upssched is
> >> only useful to control the server running the daemon itself? Or are the
> >> events only passed on after the timer of upssched is completed?
> > If I understand the way you're thinking about the events, we have a
> > slightly different way of broadcasting from the way you describe it.
> >
> > Modulo the access rules, any machine can use upsmon to connect to the
> > master. So in that sense, the events that trigger upsmon actions are
> > "broadcast" (not in the networking sense) to any connected machine.
> I was wondering if upsmon client machines are working as autonomous as I
> think they are or they the can be manipulated from a central point (a
> master UPS server running upssched which can manipulate events/flags so
> one can have single point where one can cancel shutdowns or force
> machines to go down).

I don't think we have this sort of selectivity built-in.

There is a pseudo-driver called "dummy-ups" which could be used to
pass status along to other NUT clients. Your upssched script can then
call upsrw to modify the ups.status variable on the dummy UPS.

> So I used 'broadcast' to describe to process of upsmon clients listening
> to the daemon and the events/flags it is generating (which I suspect
> what is happening opposed to an upssched process controlling (the timing
> of) events/flags).
> >> - can events/flags be manipulated? (from within the upssched script on
> >> the server running the deamon)
> > You can cancel running timers and force a shutdown, but that's all I
> > know how to do. (Someone else more familiar with upssched might have
> > some other insights.)
> Yes, ok, but I was kind of looking for the ability to let an upssched
> script on one server change flags so the behaviour of an upsmon client
> on another server is changed.

I think that setting up a dummy UPS process on the VM host machine
might allow you the sort of hierarchy that you seem to need in order
to shut things down in the right order.

> >> - how do servers configured as NUT master handle stale servers
> >> configured as slaves? Do they keep waiting?
> >
> > Do you mean "stale" as defined in the "Dead UPSes" section of the
> > upsmon(8) man page? Also check out "HOSTSYNC" in upsmon.conf(5).
> "stale" as in: windows server running winnut/upsmon has a file open and
> windows asks "do you want to save this file?" instead of just going down
> as it is supposed to do because the process handling the file has become
> zombie. If the UPS master server would wait for this slave/client it
> will wait for infinite time.

That sounds like it would be handled by HOSTSYNC. Again, having two
layers of NUT drivers (one representing the real hardware, and a dummy
driver for the guest OSes) sounds like it would allow you to cleanly
shut down the host OS even if the guests are cut short by HOSTSYNC
timing out.

> >> - one of the servers is a Virtual Machine server running various VMs.
> >> These VMs aswel as the server itself all run NUT but an extra dependency
> >> is introduced here. The main server must de downed last. Any insights on
> >> this?
> >
> > This probably depends on your VM, but in VMWare, you can configure the
> > host system to gracefully shut down the guest OSes as part of the host
> > shutdown process. You will most likely need to extend some of the
> > timeouts to account for this extra shutdown time.
> yes. The trick of course is to have enough battery power to let both the
> server and VMs to shutdown gracefully.

Here is a silly question - can you just put the guest OSes to sleep?
That should take a lot less time than shutting them down. In Windows,
I suspect that putting the guest OS to sleep would cause the virtual
network adapter to report a loss of link, so the network stack should
clean itself up when you restart later.

-- 
- Charles Lepple