[Nut-upsdev] Questions about failover architecture

[Jim Klimov]

Hello, and thanks for raising this discussion.

FWIW, the idea is (very) slowly brewing for at least a decade - backlogged
since https://github.com/networkupstools/nut/issues/273 (which proposes to
implement this over dummy-ups or clone drivers as they already have ways to
talk to other NUT drivers to represent them for various purposes).

There is a little collection of related tickets seen by GitHub tag:
https://github.com/networkupstools/nut/issues?q=state%3Aopen%20label%3A%22Data%20multipathing%22

General thoughts collected so far are that:
* Failover differs from multiplexing :) (Using one driver at a time or
several at once)
* Practical goals may include having best info about the device, with each
single driver/protocol only offering a partial aspect, and the redundancy
against loss of one of the connections (e.g. serial/USB + SNMP).
* Different drivers (or even e.g. SNMP mappings to numerous served MIBs in
the same driver, see https://github.com/networkupstools/nut/issues/2036)
can offer different insights into the device - sets of named data points,
their precision, setable variables and instant commands. When multiplexing,
we need a way (automatic and/or user-tunable) to select which variant we
prefer (exclusively, or what to try first - in case of commands or
writeable settings).
* The approach of `clone*` drivers (which talk to another driver directly
over local socket) and recent advances in `upsdrvquery.{c,h}` may be more
applicable than using a `dummy-ups` driver (is a NUT networked protocol
client when going in relay/proxy mode) that I initially thought could be
useful here.

But so far nothing has been fleshed out beyond that (AFAIK)...

Hope this helps,
Jim Klimov



On Fri, May 9, 2025 at 12:37 PM Sebastian Kuttnig via Nut-upsdev <
nut-upsdev at alioth-lists.debian.net> wrote:

> Hi all,
>
> Yesterday’s PR #2945 got me thinking about my basic failover setup and
> raised
> some questions I didn’t want to derail the PR with—hope this is the right
> place
> to ask. Apologies if not.
>
> The PR includes this note:
>
> > NOTE: There is currently no support for "multiplexing" information or
> > commands for devices with multiple-media/multiple-driver access, e.g. to
> > gain redundant connection or a better data collection than any one
> driver
> > provides. For some devices it may be possible to run several drivers
> > independently (probably for your monitoring system to cherry-pick data
> > points from one driver or another), while others might only enable any
> one
> > link exclusively.
>
> That raised a few questions:
>
> - Is there any recommended or emerging approach for UPS failover using
>   multiple devices or drivers? From the note, it sounds like this isn’t
> widely
>   supported yet.
>
> - Would there be interest in developing a driver (or utility) specifically
> aimed
>   at supporting failover logic within NUT?
>
> For context: I currently use a custom NUT driver that polls an HTTP(S)
> endpoint
> which aggregates `upsc` dumps and handles failover logic outside of NUT.
> The
> driver itself is simple—it just reports what it gets, much like `upsc`.
>
> This setup works, but may be heavier than needed for basic failover use
> cases.
> I’ve been thinking about splitting the responsibilities into two drivers:
>
> - `http-ups` (or `clone-http`): polls an HTTP(S) endpoint and reports
>   `upsc`-style data; maybe useful for development or external handling.
>
> - `failover`: monitors the sockets of other local drivers and promotes a
>   primary according to some logic, if the current one fails; basic
> internal handling.
>
> Does this approach make sense in the broader NUT architecture? Would this
> be
> something worth developing or upstreaming?
>
> Thanks!
> _______________________________________________
> 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/20250509/7b988d36/attachment.htm>