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

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

[-- Attachment #1.1: Type: text/plain, Size: 3543 bytes --]

On Fri, 2004-07-16 at 17:04, jamal wrote:

> > Has vrrp some authentification mechanism?
> 
> They (at least used to) claim to be able to do so.

Hm... Quote from draft-ietf-vrrp-spec-v2-08.txt
5.3.6.1 Authentication Type 0
5.3.6.2 Authentication Type 1
5.3.6.3 Authentication Type 2

1. 8bit virtual host ID.
2. Plain password.
3. HMAC.

I think even 3 is not good.
They do strong signed digest, but it does not have any kind of counter
so i do not see replay attack prevention.

> > Can it be used over IPv6? (CARP also can't but it is _very_ easy to
> > add, I just don't have IPv6 network setup to test).
> 
> Theres effort to have it do v6.
> http://www.ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-06.txt
> I agree its lame to have it as an after thought it seems

* VRRP for IPv6 does not currently include any type of authentication. *


> > > Can you explain a little more what you mean by "attching" to
> > > master/slave?
> > 
> > Consider using some abstraction layer which makes some decisions based
> > on knowledge of current HA state.
> 
> sure; make it an API/callback/event to/from the carp daemon to other
> applications.
> 
> > It looks like we do not understand each other :)
> > Here is the explanation of the ct_sync:
> > http://cvs.netfilter.org/netfilter-ha/README?rev=1.2&content-type=text/vnd.viewcvs-markup
> > 
> > Harald Welte will have a talk about ct_sync at OLS.
> 
> 
> Ok, good. Maybe if you too come to OLS we can settle this ;->

:) Unfortunately no...

> Looking at what HArald has, the infrastructure seems to be the correct
> flavor. Seems something gets sent to user space via netlink and gets
> delivered via keepalived.
> I think the CARP loadbalancing feature is an improvement over what is
> being suggested by Harald.
> 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 ;->

Harald, sorry :)

> > > What do you mean realtime traffic?
> > > Is it something that can be achieved by qos prioritization?
> > 
> > Yes it can. But who will control prioritization mechanism?
> > Maybe userspace.
> > But with such approach we need to create each time we need kernel access
> > a kernel agent with it's own kernel<->user protocol, it's own connect
> > to master/slave arbiter...
> > With CARP just create one function in kernelspace and register it in
> > CARP using provided mechanism.
> 
> bah.
> Ok, now you are forcing me to draw diagrams.
>
> I attached to avouid it being mangled.

I will draw one too.

> > > In the end CISCO is going to be the loser in this of because 
> > > something like CARP will take off and it cant talk to them. At the
> > > moment though they do have the market so interoping with them is
> > > valuable.
> > 
> > It is just marketing...
> > The better software the more market it can eat. Theoretically...
> 
> I am afraid even if that sounds logical it doesnt work like that.
> Too many stupid people. If it worked like that MS would be dead and
> buried a few years ago.

For those who cares they are already done.

> > I have great confidence that Theo de Raadt will not include non
> > patent-free code in OpenBSD.
> 
> I hope he is a lawyer or has some good lawyer advising him;->

He is an OpenBSD creator, so he is just a bit more paranoidal than
others :)

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

Crash is better than data corruption. -- Art Grabowski

[-- Attachment #1.2: carp_diagram.1 --]
[-- Type: text/plain, Size: 2745 bytes --]

No, your diagram should looks like this:

         User space
                    +----------------------------------------------------------+
		    |                                                          |
                    |  +-------------------------------------+                 |
		    |  |                                     |                 |
+-------+         +-------+         +---------+         +-------+          +-------+          
| App#X | <-----> | CARPd | <-----> | ctsyncd | <-----> | App#X | <----->  | App#X | <-----> 
+---+---+         +---+---+         +---+-----+         +---+---+          +---+---+         
                      |                 |                   |                  |              
                      |                 |                   |                  |              
   ------------------------------------------------------------------------------------------
           Kernel
        network I/O etc

Or only have one BUS(and it is actually implemented using netlink).

You need to connect each application daemon to carpd, even using broadcast netlink.
And for any in-kernel access you will need to create new App and new kernel part.

If we will extrapolate it we can create following:
userspace carp determines that it is a master, it will suspend all kernel memory or dump /proc/kmem
and begins to advertise it. Remote node receives it and has pretty the same firewall settings, 
flow controls and any in-kernel state.
No matter that it takes a long time.


It make sence if App#X needs userspace access only.
But here is other diagram:

                                        userspace
                 |
-----------------+-------------------------------
                CARP                  kernelspace
                 |
                 |
+----------+-----+-----+---------+-------
|          |           |         |
ct_sync  iSCSI       e1000      CPU


My main idea for in-kernel CARP was to implement invisible HA mechanism suitable for in-kernel use.
You do not need to create netlink protocol parser, you do not need to create extra userspace overhead,
you do not need to create suitable for userspace control hooks in kernel infrastructure.
Just register callback.
But even with such simple approach you have opportunity to collaborate with userspace. If you need.

Why creating all userspace cruft if/when you need only kernel one?


Resume: 
With your approach any data flow MUST go through userspace arbiters with all overhead and complexity.
With my approach any data flow _MAY_ go through userspace arbiters, but if you do_need/only_has 
in-kernel access than using in-kernel CARP is the only solution.

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