[nf-failover] Re: [RFC] ct_sync 0.15 (corrected)
hadi at cyberus.ca
Tue Sep 28 04:41:17 CEST 2004
On Mon, 2004-09-27 at 09:39, Harald Welte wrote:
> 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.
So if understood correctly the issue is as described by Krisztian:
On Mon, 2004-09-27 at 09:30, KOVACS Krisztian wrote:
> The main problem is with NAT and preserving the uniqueness of
> tuples in the whole cluster, and unfortunately this would make a lot of
> things much more complicated. So, even if the protocol would be
> completely multi-master compatible ct_sync would be capable of
> single-master operation.
If you have two machines A and B, assuming they are symetric (exactly
same internal and external IPs) then i should be able to send state from
A->B and B->A and have both B and A updated (if such state doesnt exist).
With above if i decide i want to have two nodes as master, they both
generate and accept state update messages.
> 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.
As i see it you need 3 states:
Master - accepts and generates sync messages
slave - only accepts syncs
init - unknown; does neither
If you didnt have this safeguard then i should be able to achive
master/master on two nodes (even if for starters i assume symetric
setup). ct_sync in itself should not attempt to be too smart and have a
built-in protocol IMO - there is no point in reinventing the wheel;
people have spent years researching HA protocols, good idea to just use
More information about the netfilter-devel