[nf-failover] Re: [RFC] ct_sync 0.15 (corrected)

jamal hadi at cyberus.ca
Mon Sep 27 15:07:53 CEST 2004


Hi Harald,

On Sat, 2004-09-25 at 03:52, Harald Welte wrote:

> > I havent actually run it - can you confirm this is impossible? 
> > if ct_sync was blind i.e it just did what it was told "become master" or
> > "become slave" regardless of who else is master, then it would be more
> > usable - leave policy to whatever tells it to switch.
> 
> well it exactly does this, with an additional security:  A master will
> be downgraded to slave as soon as another master announces itself.  This
> is a security guard against invalid mode of operation.

I think it would be better to separate the election process (who is
master) from the syncing code. For some reason i thought this separation
was there (and that all you had to do was bag some /proc entry). 
i.e if VRRP is the code that makes the decision that it wants you to be
the master, thats how you become master. If someothericandohabetter (eg
forCES) protocol wants you to be the master, thats how you become the
master. There is no point in inventing a new HA scheme.
And if you do it should probably be in user space (there is no
perfomance issues with it) i.e its such a protocol (in user space) that 
should tell your syncing code to send syncs or not.
Unless i missed something fundamental.

cheers,
jamal





More information about the netfilter-devel mailing list