similar to: Questions about failover architecture

P.S. To articulate better what I am unclear about from your message: `nutshutdown` seems to run `@SBINDIR@/upsdrvctl shutdown`. >From my understanding, this would command - all - `ups.conf` UPS to shutdown. So this would already include the UPS monitored by any failover/multiplexing driver. In contrast, `upsdrvctl shutdown` would start up all these drivers again, respectively. What kind of

Hello Jim, I am following the direction of the `clone` drivers, although using the modern `upsdrvquery.c` API. Essentially I am parsing the protocol lines directly reading from the driver sockets, as the clone drivers do. As for ups.conf, I start up as follows without problems: [ups] driver = dummy-ups port = /etc/nut/5E.dev [ups2] driver = dummy-ups port = /etc/nut/APC.dev [failover] driver

Thinking of it, the service-aware nut-driver-enumerator script has ways to set dependencies of a driver on other units in the system, depending on driver type. A couple of lines added there would be useful to ensure the failover/multiplex driver(s) start after the "real" driver units they scrape data from, and it would be a "soft" dependency (real driver unit may crash without

Good point, I guess I thought it knew which UPSes are getting the FSD treatment. Maybe this should also get revised eventually (e.g. a "primary" monitoring system not fed by the UPS it is wired to should never FSD itself due to the outage, but should ensure that UPS gets powered off or power-cycled when no "secondary" clients remain). Then maybe not much is needed at this

Hello Jim, Many thanks for the detailed insights?also the clarification on driver multiplexing versus failover, that was very helpful. While I don?t have much to contribute on the multiplexing front, I may take a shot at exploring the failover and proxying drivers. At the very least, it might be useful for my personal requirements; at best, perhaps to others as well, or even in support of later

Sounds great, thanks for the update! For communications with the other drivers (from failover or multiplexor), I suggest using the local driver socket line the clone* drivers do: this removes a dependency on `upsd` both for the service startup (no chicken-and-egg issue of drivers before upsd, but upsd before the failover driver) and for FSD end-game (after all services stopped, we just need to

Hello again, I can report back that my failover driver is progressing nicely, and a lot of things seem to overlap with what could very well also be useful and maybe used eventually for a future multiplexing driver. Basically, my failover logic takes driver names (sockets) in comma-separated form from the `port` variable and keeps track of these drivers, monitoring their information and failing

Wow, that's quite the tale! I take away from this: There is a real example of wanting to merge two information sources. It's very complicated. Anybody wishing to succeed in a very complicated situation needs to really pay attention, to twice as many things as they thought when they started. It's unclear how to generalize from this to a solution that will work for the

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

Jim Klimov <jimklimov+nut at gmail.com> writes: > 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. Sure, but that's for things whose failure is a much bigger deal.

Hi, Please forgive my terminology, still a bit new to T1s and such. I'm looking for a way to have 5 T1s from a carrier terminate into some type of box (multiplexer?), then be able to plug 7 asterisk servers into that box (each with single port T1 card) and be able to have 2 * servers go down at any given time and not actually have the carrier see that anything has happened. Obviously if a *

Hi, I read in the Asterisk Whitepaper, that you can run two cloned servers, one as a primary, one as a backup, and have them automatically failover to the other unit when it crashes, or when you need to restart it. The primary application of course, would be ensuring calls can be made when frequent updates are being handled, or when an update must be restarted on a busy network. The term

Hi List, Does anyone know of a good dual wan router that can handle SIP well and can failover between connections if there is a SIP issue on one of the lines (meaning there still is a connection however there isnt enough bandwith or sip packets arent going thru etc.) ? Thanks. Dovid -------------- next part -------------- An HTML attachment was scrubbed... URL:

> Interesting concept. It would seem obvious that all networking has to be on UPS to have a reasonable setup. > I was trying to ask for real examples of situations/problems people have. I do get the theoretical point. Got it. One thing that did bite me when I was a young sysadmin was not so trivial: the UPSes were nice and fancy with SNMP monitoring/management, powered a rack of indeed

I have a device on my network that is not DHCP and I dont know the IP address of it and it has not method of finding it or changing it unless you know the IP address (setable by browser). Is there a way on linux, based on MAC address, to get the IP of the unit? Thanks, Jerry

On Thu, Apr 19, 2018 at 06:42:02PM -0700, Sridhar Samudrala wrote: > +#if IS_ENABLED(CONFIG_NET_FAILOVER) > + > +int failover_create(struct net_device *standby_dev, > + struct failover **pfailover); Should we rename all these structs net_failover? It's possible to extend the concept to storage I think. > +void failover_destroy(struct failover *failover); > + > +int

On Mon, 7 May 2018 15:10:44 -0700 Sridhar Samudrala <sridhar.samudrala at intel.com> wrote: > +static struct net_device *net_failover_get_bymac(u8 *mac, > + struct net_failover_ops **ops) > +{ > + struct net_device *failover_dev; > + struct net_failover *failover; > + > + spin_lock(&net_failover_lock); > + list_for_each_entry(failover,

On Mon, 7 May 2018 15:10:44 -0700 Sridhar Samudrala <sridhar.samudrala at intel.com> wrote: > +static struct net_device *net_failover_get_bymac(u8 *mac, > + struct net_failover_ops **ops) > +{ > + struct net_device *failover_dev; > + struct net_failover *failover; > + > + spin_lock(&net_failover_lock); > + list_for_each_entry(failover,

On Mon, 7 May 2018 15:10:44 -0700 Sridhar Samudrala <sridhar.samudrala at intel.com> wrote: > This provides a generic interface for paravirtual drivers to listen > for netdev register/unregister/link change events from pci ethernet > devices with the same MAC and takeover their datapath. The notifier and > event handling code is based on the existing netvsc implementation. >

On Thu, 24 May 2018 09:55:14 -0700 Sridhar Samudrala <sridhar.samudrala at intel.com> wrote: > --- a/drivers/net/hyperv/Kconfig > +++ b/drivers/net/hyperv/Kconfig > @@ -2,5 +2,6 @@ config HYPERV_NET > tristate "Microsoft Hyper-V virtual network driver" > depends on HYPERV > select UCS2_STRING > + select FAILOVER When I take a working kernel config, add