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

[Olaf Zevenboom]

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).
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.
>> - can upssched also be implemented on windows machines?
> It's possible, but I don't know how well the code will compile on 
> Windows. Have you checked to see if WinNut has the capabilities you need?
>> - 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.
>
>> - 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.
>
>
> I think you can also set a longer delay in your SHUTDOWNCMD 
> commandline on the host upsmon.conf than what you use in the slaves, 
> but that will not account for variations in the amount of time it 
> takes to shut down the guests.
I feel like the shutdown time is the only 'hard' parameter which can be 
used to control the sequence in which servers can be shutdowned.
>
> --Charles Lepple
> clepple at gmail
-- 
Olaf Zevenboom