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

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]

On Thu, 2004-07-15 at 20:07, jamal wrote:

> > > 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...
> 
> Yeah, I know ;-> and probably thats what the opnebsd people did.
>  
> I still think it should live in user space.  This should apply to
> anything thats control related because such things tend to be
> continoulsy enrichned with features. ARP unfortunately is in there; one
> of my pet perpetual projects is to totaly rip it off. Theres already
> hooks to deliver to user space today and Alexey has a daemon for it, not
> sure how widely used it is.

Userspace is too slow.
It can only initiate master's failover, load balancing is a good example
here - userspace _itself_ can not control real time traffic.

> > > 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:
> 
> Thank you. 
> I think a better idea would be to implement a sync message
> within CARP instead of that pfsync app doing its own thing. Unless i
> misread, pfsync seems to be a separate app.
> This way more than one app can use it via the CARP daemon
> in user space to sync state of their choice (with whatever pfsync does
> being one of many). 

ct_sync module does this.
It uses connection tracking and sends firewall state across slaves.
CARP is separate by design - anyone may "attach" to master/slave
failover.

> This is an example of a rich application and further justification for
> it to live in user space.

If it will live in userspace, it just can not control realtime traffic
and even provide some mechanism to achive this.

> > 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.
> 
> It is valuable, just doesnt belong to the kernel.
> BTW, i saw some claim that this is patent-free as opposed to VRRP?
> I do hope it takes off.  What exactly is the patent issue that was at
> stake? I couldnt tell from the song lyrics ;->

:) Cisco + hsrp == vrrp, but the former is patented.
Here is quote from Ryan McBride, an author of the CARP:

* P.S. If anyone has concerns about the Cisco's patent #5,473,599 and
how their claim that it applies to VRRP has forced us to design our own
incompatible protocol, don't talk to us. Instead, call Cisco's lawyer at
408-525-9706, or email him: rbarr@cisco.com *


> One valuable thing that could be done is while still avoiding any patent
> issues make it interop with VRRP.

VRRP is not secure, it is protocol dependent, it is not free...

> cheers,
> jamal
-- 
	Evgeniy Polaykov ( s0mbre )

Crash is better than data corruption. -- Art Grabowski

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]