Charles,
On 2017-06-26 03:43, Charles Lepple wrote:
On Jun 25, 2017, at 8:53 AM, Philip Rhoades wrote:
I don't understand why most of the UPS offerings available do not come
standard with a LAN port? Why is this?
As others have mentioned, it probably comes down to cost for a port
that is not frequently used.
Something to consider is that there are add-on cards with LAN ports
for mid- to upper-tier UPSes. Some cards also have environmental
monitoring options as well.
On the other hand, these cards do not seem to be high-volume items,
and the prices reflect that. If you don't need fancy temperature
sensing, a Raspberry Pi or other single-board computer is IMHO a
better way to spend that money (and it will probably turn out to be
more versatile).
One thing about the NUT master/slave architecture is that it forces
you to consider the shutdown order. The NUT master is responsible for
commanding the UPS to turn off the power, so at that point, the master
system should not be depending on any other systems for their
services. A LAN card with SNMP doesn't really enforce this hierarchy,
but then again, there are probably some high-availability cases where
SNMP makes more sense.
Do people have suggestions about my options? I have two main machines
- say 250-400W total and a few small devices inc a Billion router and
some USB devices.
Be sure to factor your network infrastructure into that power estimate
- you will want the network links between NUT master and slave systems
to be on battery power as well, or else the master will resort to
guessing the status of the slaves.
It would be nice to have at say 5-10 minutes battery backup before
sending shutdown messages to the Linux machines.
When you take the 5-10 minutes of runtime and turn that into a
requirement for battery capacity, it is worth considering what amount
of reserve power you would want in case you need to briefly power up a
machine during an extended outage. I would also recommend buying an
UPS that allows you to adjust its low battery threshold in terms of
estimated remaining runtime (and not just percentage of full charge),
as this should prevent surprises later as the battery ages. (The UPS
should keep track of changes in runtime for a given load as part of
its periodic calibration, automatic or manual.) The NUT variable for
this limit is "battery.runtime.low" (expressed in seconds).
This brings me to the Device Dump List:
http://new.networkupstools.org/ddl/ (or
http://networkupstools.org/ddl/ if the first link is not working).
Because suggestions are an inherently subjective topic, we have some
user-provided data dumps of the readable and read/write values
provided by many UPS vendors. We also try to flag values that are
problematic in some way (wrong scale factor, doesn't ever update,
etc). Ideally, we would fix this in the driver, but in some cases,
that can be difficult to fix without breaking something else.
A more subtle aspect of the DDL is that you can see how the underlying
firmware changes over time for the same marketing model name. For
instance, there are two versions of the Tripp-Lite OMNIVS1000 with
different internals, and as such, slightly different feature sets.
Feel free to ask about any of these results - the underlying DDL
repository has some links back to the source of these reports. You can
often find discussions for other devices in the nut-upsuser archives.
Wow! Thanks for all of that! I will start looking at it all . .
Regards,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: p...@pricom.com.au
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
