[Top] [All Lists]

Re: [nf-failover] Re: [1/2] CARP implementation. HA master's failover.

To: KOVACS Krisztian <hidden@xxxxxxxxxx>
Subject: Re: [nf-failover] Re: [1/2] CARP implementation. HA master's failover.
From: Harald Welte <laforge@xxxxxxxxxxxxx>
Date: Mon, 19 Jul 2004 22:38:42 -0400
Cc: hadi@xxxxxxxxxx, johnpol@xxxxxxxxxxx, netdev@xxxxxxxxxxx, Netfilter-failover list <netfilter-failover@xxxxxxxxxxxxxxxxxxx>
In-reply-to: <1090221367.2551.27.camel@xxxxxxxxxxxxxx>
Mail-followup-to: Harald Welte <laforge@xxxxxxxxxxxxx>, KOVACS Krisztian <hidden@xxxxxxxxxx>, hadi@xxxxxxxxxx, johnpol@xxxxxxxxxxx, netdev@xxxxxxxxxxx, Netfilter-failover list <netfilter-failover@xxxxxxxxxxxxxxxxxxx>
References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@xxxxxxxxxxxxxxxx> <1089905244.6114.887.camel@uganda> <1089907622.1027.48.camel@xxxxxxxxxxxxxxxx> <1089910760.6114.967.camel@uganda> <1089912285.1028.93.camel@xxxxxxxxxxxxxxxx> <20040715235313.69897131@xxxxxxxxxxxxxxxxxxxx> <1089983064.1060.1328.camel@xxxxxxxxxxxxxxxx> <1090221367.2551.27.camel@xxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040523i
On Mon, Jul 19, 2004 at 09:16:07AM +0200, KOVACS Krisztian wrote:
>   Unfortunately this is not the case, as Evgeniy already mentioned.
> ct_sync is currently an completely in-kernel solution, with all the pros
> and cons of that. (Yes, it could be done in userspace with some minimal
> kernel code, and yes, it had a few advantages over the current solution.

I strongly disagree with this.  Or, let's say - while it is doable in
userspace, it would be at a very high cost... additional latency, lots
of more per-packet data copying, and the possibility of  being starved
by some other random userspace application.

> > I think the CARP loadbalancing feature is an improvement over what is
> > being suggested by Harald.
Yes, I would also be interested in what Jamal was referring to.  I
cannot really remember having anything suggested as 'cluster manager'.

> > I have to say as well i am shocked that state is just being transfered
> > blindly - but i will deal with Harald when he shows up in Ottawa ;->
>   Would it be possible to summarize your ideas here? Yes, I know it is
> easier and faster to talk about those things in person, but
> unfortunately I won't be there in Ottawa, but am of course seriously
> interested in all ideas related to ct_sync...

I was just talking to Jamal today.  His basic proposal was something

more than 90% of all connections last longer than 10 seconds, so we only
replicate connections that exist for more time.   I argued that this was
not the level of synchronization that we want to achieve, and that in
such a case he could just skip any kind of sync code and live with the
existing 'connection pickup' code of ip_conntrack (ACK from both sides
being able to establish connection even if no initial SYN handshake was

Jamal apparently wasn't aware of this.

Anyway, there will be some more discussion after my presentation at OLS
later this week.  I'll keep you posted.

>  Regards,
>    Krisztian KOVACS

btw: I think we should remove netdev for further discussions on ct_sync,
since there is a more specific mailinglist.

- Harald Welte <laforge@xxxxxxxxxxxxx>   
  "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

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>