Arjen de Korte ha scritto:
1) Both netxml-ups drivers can't connect at the same time via NSM to
their respective NMC's. We must have two instances of the netxml-ups
driver running (to provide access to all variables in the UPS) and as
far as I can see we can only accommodate one NSM client (due to the
listening socket that is needed for the callback from the NMC's) per host.
No. This would be a problem when using the UDP protocol, that I didn't
implemented, where there is a single socket reading broadcast messages
sent by the UPSes. In such case we would need the driver approach (but
that breaks the single_UPS--single_driver_instance design [1]) or the
new deamon approach (that shall take care about talking to the NMC
directly). Otherwise this is false and you can run every netxml-ups
instances you want (or run UDP in a single UPS scenario only).
2) You can't make *any* changes to the clients,
I have never suggested a change in upsmon. However a mgemon client can
be certainly created instead. But I'd like a reply about the current
support for those redundancy configuration before thinking about this.
So to the
clients, the individual outlets of the two UPS'es would need to appear
as completely separate devices,
They do appear separate devices using the subdriver approach, with the
ups.status parameter controlled by the NSM protocol if present. We would
see just a single virtual UPS in that driver approach I proposed
instead, so let's discard this solution if this is a problem, that's ok.
The only way I see how to solve this without rewriting half the upsd
server and/or requiring changes to the clients, is by creating a
'netnsm-ups' listener that would connect to all NMC's, without actually
providing a real/virtual UPS and create a special kind of clone driver,
that would connect both to one of the 'netxml-ups' drivers running and
also 'netnsm-ups' (to grab the 'ups.status' line).
[...]
I have not fully understood the config proposed but I got the idea and
it's fine. But if we don't care about UDP the subdriver approach do the
same thing (changing the status accordingly to the NSM protocol ALARMS)
in a easier way directly in the driver.
They are all valid solutions, with different pros and cons, so back to
my original question: which one is the best? Which one can support
redundancy?
However I'd like to know about the redundancy configurations natively
supported by NUT, and so if upsmon can take care about that for NSM too.
Regards,
Marco
[1] Not with the solution you proposed later.
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
