[nf-failover] Re: [RFC] ct_sync 0.15 (corrected)
laforge at netfilter.org
Mon Sep 27 15:39:05 CEST 2004
On Mon, Sep 27, 2004 at 09:07:53AM -0400, jamal wrote:
> 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.
I totally agree with you, jamal. And in fact this is exactly what we
have. You tell one box it is master, and it becomes master. You tell
a box it is slave, and it becomes slave.
There is just a minor addition in one case, where we want to safeguard
against a (currently) invalid mode of operation. As soon as ct_sync
supports multiple master, this safeguard will certainly be removed.
But for the current code, unless somebody shows to me that it severely
limits some use of ct_sync, or it causes practical problems, I don't see
why we should remove this safeguard.
- Harald Welte <laforge at netfilter.org> http://www.netfilter.org/
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/netfilter-devel/attachments/20040927/28f18f92/attachment.bin
More information about the netfilter-devel