[Top] [All Lists]

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

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: [1/2] CARP implementation. HA master's failover.
From: Evgeniy Polyakov <johnpol@xxxxxxxxxxx>
Date: Thu, 15 Jul 2004 19:55:36 +0400
Cc: netdev@xxxxxxxxxxx, netfilter-failover@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1089905244.6114.887.camel@uganda>
Organization: MIPT
References: <1089898303.6114.859.camel@uganda> <1089898595.6114.866.camel@uganda> <1089902654.1029.23.camel@xxxxxxxxxxxxxxxx> <1089905244.6114.887.camel@uganda>
Reply-to: johnpol@xxxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, 2004-07-15 at 19:27, Evgeniy Polyakov wrote:
> On Thu, 2004-07-15 at 18:44, jamal wrote:
> > Evgeniy,
> > 
> > Why do you need to put this stuff in the kernel?
> > This should be implemented just the same way as VRRP was - in user
> > space.
> Hmm...
> Just because i think it works better being implemented in the kernel? :)
> I don't think it is a good answer thought.
> It is faster, it is more flexible, it has access to kernel space...

Just an addition[from private e-mail]:

> would it be possible to do load balancing at the network level with a 
> userland only implementation? 
> OpenBSD's CARP does load balancing through Source Hashing (SH), which
> lacks support for.

Userspace can't in principle.
Current kernel implementation can't too, but it can. In principle.

But better implementation should use both carp and ct_sync and some load
balancing code, which should link ct_sync and carp.
OpenBSD has one disadvantage in this regard: it is not modular, so their
carp hooks live in if_ether.c.
In Linux we just need to use connection tracking.
ct_sync makes not exactly it but close to the idea.

> > BTW, is there a spec for this protocol or its one of those things where
> > you have to follow Yodas advice?
> Exactly :)
> Here are all links I found:
> VRRP2 spec.
> I do want this to be in the mainline kernel, but actually I even don't
> think anyone will apply it.
> It is too special stuff for generic kernel, it has reserved 112 vrrp
> protocol number and so on...
> So if developers decide not to include or even not to discuss this cruft
> I will not beat myself by my heels. :)
> It just works as expected, it is reliable and simple.
> And it does it's work, so HA people would like it.
> > cheers,
> > jamal
        Evgeniy Polaykov ( s0mbre )

Crash is better than data corruption. -- Art Grabowski

Attachment: signature.asc
Description: This is a digitally signed message part

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