[nf-failover] Re: [RFC] ct_sync 0.15 (corrected)
codeslinger at gmail.com
Tue Sep 28 16:24:38 CEST 2004
On Tue, 28 Sep 2004 15:58:52 +0200 (CEST), Henrik Nordstrom
<hno at marasystems.com> wrote:
> On Tue, 28 Sep 2004, KOVACS Krisztian wrote:
> > There are other solutions for that problem, for example Harald's
> > ClusterIP code. If we could integrate that with ct_sync we would be able
> > to do multi-master packet filter clusters without any load balancers
> > before the cluster. If the NAT core would be integrated with ClusterIP's
> > hash to avoid conntrack clashes we could do this without statically
> > assigning different NAT addresses to each node.
> Any ideas on how would this work?
> Lets reason around the common MASQUERADE case where an internal network
> needs to be SNAT:ed when going out to the Internet.
Forgive me for bringing this back up, but...
I believe that Saru handles this problem by assigning "blocks" (a
block being a fixed-sized range of units, e.g. 512 source ports in
sequence) of IPs and ports to various nodes in the cluster and each
node only handles the IP/ports in its assigned blocks. The lookup is
just a bitop so its fast and this would handle the MASQUERADE case
mentioned above nicely. The blocks are handed out by a userspace
daemon as nodes enter and leave the cluster.
Would this not work?
[ Tobias DiPasquale ]
More information about the netfilter-devel