Hallo there. I'm new to this list and also to NUT. Our previous ups-system was APC based and apcupsd was serving the ordered shutdowns in our network. Our new ups is made by MGE and that's why we can't use apcupsd anymore. This led us into trouble. Our network system is quite complex and we need shutdown sequence levels. The servers depend on each other because of NFS and SQL connections and the like. We have one 60kVA UPS and more than 20 servers/routers/SANs supplied with energy by it. With apcupsd we could confiure the servers to shutdown on a specified battery level or the remaining time. Is there a way to do this with NUT anyhow? I thought about using the schedule mechanism with own bash scripts but this won't work on windows. In the docs is nothing written about such a feature. BTW, is there a feature request website for NUT somewhere? Thanks Lars
Hi there again, because nobody replied I decided to enhance apcupsd with the knowlegde of the snmp communication to our UPS. It works for me. I'm unsubscribing some time soon. Regards Lars Lars T?uber <taeuber at bbaw.de> schrieb:> Hallo there. > > I'm new to this list and also to NUT. > Our previous ups-system was APC based and apcupsd was serving the ordered shutdowns in our network. > > Our new ups is made by MGE and that's why we can't use apcupsd anymore. This led us into trouble. > Our network system is quite complex and we need shutdown sequence levels. The servers depend on each other because of NFS and SQL connections and the like. > We have one 60kVA UPS and more than 20 servers/routers/SANs supplied with energy by it. > > With apcupsd we could confiure the servers to shutdown on a specified battery level or the remaining time. Is there a way to do this with NUT anyhow? > I thought about using the schedule mechanism with own bash scripts but this won't work on windows. In the docs is nothing written about such a feature. > BTW, is there a feature request website for NUT somewhere? > > Thanks > Lars > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser-- Informationstechnologie Berlin-Brandenburgische Akademie der Wissenschaften J?gerstrasse 22-23 10117 Berlin Tel.: +49 30 20370-352 http://www.bbaw.de
On Fri, Jan 30, 2009 at 7:32 AM, Lars T?uber <taeuber at bbaw.de> wrote:> Our network system is quite complex and we need shutdown sequence levels. The servers depend on each other because of NFS and SQL connections and the like.There is a bit of sequencing in the master/slave protocol, but I have not had the time to set something up to try your particular situation.> BTW, is there a feature request website for NUT somewhere?I guess this is "too little, too late", but we use Alioth: http://alioth.debian.org/tracker/?atid=411545&group_id=30602&func=browse -- - Charles Lepple
Lars, The win client includes several timers that can be used to simulate what you seek. There is a timer that can be set to cause the server to shut down after X minutes on battery. You can set this to the needed times giving you the sequencing you are looking for. The down side is the issue of mid shutdown recovery. On a large UPS system with the windows client you have to cycle power to the server to get it to reboot. Unless you have a way to switch off the output that the server is on, you will have to continue the shutdown of the entire system and then trigger a restart of the UPS unit OR require manual intervention. This is exactly the point I am facing in my system. At this point we are concerned with a clean shutdown and are willing to do a manual restart. I have about 50 ups units on campus and monitor them all with one NUT server. All of the windows clients then talk to that one master server to get the status to it's UPS unit. Mine is still a work in progress and has many things left to fix. Doug On Fri, Jan 30, 2009 at 7:32 AM, Lars T?uber <taeuber at bbaw.de> wrote:> Hallo there. > > I'm new to this list and also to NUT. > Our previous ups-system was APC based and apcupsd was serving the ordered > shutdowns in our network. > > Our new ups is made by MGE and that's why we can't use apcupsd anymore. > This led us into trouble. > Our network system is quite complex and we need shutdown sequence levels. > The servers depend on each other because of NFS and SQL connections and the > like. > We have one 60kVA UPS and more than 20 servers/routers/SANs supplied with > energy by it. > > With apcupsd we could confiure the servers to shutdown on a specified > battery level or the remaining time. Is there a way to do this with NUT > anyhow? > I thought about using the schedule mechanism with own bash scripts but this > won't work on windows. In the docs is nothing written about such a feature. > BTW, is there a feature request website for NUT somewhere? > > Thanks > Lars > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20090209/def97183/attachment.htm
Citeren Gabor Gombas <gombasg op sztaki.hu>:> The first step would be to have a _central_ way to manage when to shut a > specific class of clients down. Having to muck with upssched scripts on > every client just does not scale. IMHO the clients should just say > "hello, I'm of class X" when logging into the UPS, and it should be > upsd's job to say "clients of class X start to shut down NOW, everyone > else wait".This would still require configuration on the part of the clients to set the class. But I agree with the fact that this should be managed in a centralized way. I intend to do this by adding 'virtual' UPS devices that clients can connect to in the usual manner. By doing so, the interface to existing client applications (not only the ones we provide) remains intact. So something like big-ups op example.com (actual UPS) <whatever>@example.com (virtual UPS) In this case, clients can connect to either of the above (or more than one), which will look to them as a 'real' UPS. All the power sequencing would be handled on the server, including the decision to shutdown a certain virtual UPS. Doing so effectively means that from the moment this is added, all existing clients can start using this.> Being able to turn clients that were logged in to the UPS when their > shutdown was ordered back on is the next logical step after the above, > but for a start I'd be happy with the shutdown part.Noted. If you're not already subscribed to the nut-upsdev mailinglist, please do so, since usually changes like the above will be announced there first. Best regards, Arjen -- Please keep list traffic on the list
Citeren Marco Chiappero <marco op absence.it>:>> It's funny that you mention MGE PSP here, since except for the >> shutdown timer (reason explained in the FAQ), NUT already provides >> *all* functionality it has (including shutdown based on charge and >> runtime). What you may be missing is the fact that this requires >> setting values on the UPS through the 'upsrw' command to control the >> level when the UPS will decide the battery is low. > As far as I remember in PSP there are two different regulations, battery > charge level that triggers system shutdown and battery charge level that > set the "low battery" state. I suppose it uses the first one that > occurs. If I'm not wrong.You're wrong. :-) In MGE PSP you can set the equivalent what we call in NUT 'battery.charge.low' and 'battery.charge.restart'. The first will determine the level that triggers the 'battery low' warning (and system shutdown), but the second does something completely different. You don't want to restart your systems if there isn't sufficient battery charge left to cleanly shut them down. Imaging that the power returns, but fails after one or two minutes again (maybe the fuse that was replaced, blew again). In that time, the server will probably have restarted, but the UPS batteries will still be almost empty and there may not be enough time to shutdown cleanly. This is where the 'battery.charge.restart' level comes into play. It will make the UPS not power up the outputs again until the battery has been recharged to a certain level again (which of course should be enough to do a full restart/power down cycle). In that case, no matter how often the mains fails, there will always be enough juice in the battery to shut your systems down cleanly. See also what is written about this at the bottom of 'docs/shutdown.txt'. Generally speaking, the 'battery.charge.restart' level should be *higher* than 'battery.charge.low' (if you understood the problem, you'll know why). Best regards, Arjen -- Please keep list traffic on the list