[Nut-upsdev] Questions about failover architecture

[Jim Klimov]

I'd say this is not so much about "often enough" (or it would have been
addressed earlier), but neither are ethernet cable/port outages yet people
do LACP/trunking/bonding anyway. And "out of band" serial consoles for good
measure.

I assume issues that may be relevant are loss of networking (SNMP et al)
during a power outage, when some switch goes off, and the "out of band"
link can be used anyway to command the UPS to power cycle.

Another problem is that UPS controllers often do expose different sets of
data points or with different precision over various protocols. Even with
SNMP I saw vendor MIBs and IETF standard trees show the same data
differently (e.g. as integer and as two-digit-after-the-dot floats)
simultaneously. Merging this info (even if just for read-only queries)
would be quite a practical benefit.

Jim


On Fri, May 9, 2025 at 7:44 PM Greg Troxel via Nut-upsdev <
nut-upsdev at alioth-lists.debian.net> wrote:

> Perhaps it would be helpful to articulate what the problem is, that
> needs solving.
>
> It sort of sounds like
>
>   there are UPS units that one can access via multiple mechanisms
>   (e.g. serial and USB, or USB and SNMP/ethernet).
>
>   people are able to hook them up both ways at the same time
>
>   people have problems where
>     - the UPS keeps working
>     - the communications via method A fails
>     - at the same time, method B keeps working
>     - this happens often enough that spending time making a scheme to
>       talk to both  and integrate them, or pick one, is worthwhile
>
>
> and in total I find this surprising.  Some real examples of problems and
> desired approaches would help.
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250510/89e15c6f/attachment.htm>