[Nut-upsuser] Question about NUT config
clepple at gmail.com
Thu May 28 03:03:37 UTC 2015
On May 21, 2015, at 10:08 AM, Tony Harris <nethfel at gmail.com> wrote:
> Hi all,
> I've been doing some searching, but I am not able to find what I'm looking for so I'm hoping someone here might be able to help.
> I have NUT installed and connected to my UPS, although not configured to do anything yet. I have 2 clusters that I need to shutdown in a specific order to make sure it is all powered down correctly - I know it probably needs to happen through the scripting, but I am not sure how to implement it.
> Cluster 1 is storage
> Cluster 2 is vm hosts
> The vm hosts need to be shut down first (all of the hosts at once sent a shutdown command is fine) when there is at least 6 minutes left on the battery backup powering the storage cluster
> Once the VM hosts are shut down or when the batteries are down to 3 minutes, the storage cluster needs to:
> Properly stop the network storage - once that process completes, send a shutdown to all of the storage nodes.
> The UPS is connected to one of the storage cluster nodes, and I am able to communicate with it (so I know that part is setup properly); Should I setup the other nodes as slaves or just create a command line script on the master to go in sequence shutting everything down? If I set them up as slaves, I'm not sure how to setup NUT to tell specific slaves to shutdown in a specific order...
The whole master/slave situation is really intended for when you are starting the shutdown from the UPS low battery signal, as opposed to timing thresholds. I haven't tried something like your setup, but you could synthesize a "LB" status using runtime (override.battery.runtime.low = 360 for your example) or battery charge levels via "ignorelb": http://www.networkupstools.org/docs/man/ups.conf.html#_ups_fields
The problem is that this only provides a single timing stage. I hesitate to recommend adding a repeater with dummy-ups (and a separate set of "ignorelb" conditions) for the storage cluster - but if you have a way to test all of this on a non-production system, it's worth a try.
As for which way is easier to shut down the VMs, it will probably depend on your virtualization software, and how reliable the guests are. You might want to allow some time between a "soft" shutdown (simulating an ACPI power button), and a hard stop of the VM. I suspect that is easier to script on the host side.
clepple at gmail
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsuser