|
> By the time the LVS box needs to fail-over, the state of the failing kernel
> can not be trusted. So send the state to other LVS box may not get correct
> data and cause more problem than help. It should not have kernel involved
> at all. Just my 2 cents.
Right, but that assumes that it's the kernel itself that failed here.
There are other situations, such as cut power, failed network cables, etc,
that this would be a perfectly reasonable approach.
I don't see how you're going to get around the fact that the kernel could
be lying to the backup. You have to trust it to give you good states, or
the whole exercise is pointless, right? About all I can imagine you can
do is make sure what input you get doesn't break any rules.
Actually, that's not all, come to think of it. You could change the
kernel oops code (and/or whatever other code may be more appropriate) to
shut down the state transfer thread immediately, and notify the backup
server that it just detected an internal fault, and have it take over the
operation. This may be overly paranoid, but since part of what we're
aiming for is HA, it pays to be paranoid.
Also, even if the program is in user space, the kernel's going to be
involved, since it has to go out over the wire to the backup director
(through the serial drivers, through the tcp/ip stack, etc), so I don't
think that's a very good argument against putting this stuff in the
kernel.
Kyle Sparger
On Wed, 15 Mar 2000, Wayne wrote:
> At 10:07 AM 3/16/00 +0800, Wensong Zhang wrote:
>
>
>
> >On Wed, 15 Mar 2000, Ratz wrote:
> >
> > > I cannot get the point out of your new ip_vs_random_drop_syn function.
> > > At which point could such a function be important? Or what exactly has
> > > to occur that you want to drop a connection?
> > > I mean, standard (without ISN-prediction) SYN flooding is IMHO not
> > > possible to a 2.2.14 kernel unless you set the
> > > /proc/sys/net/ipv4/tcp_max_syn_backlog to a too high value.
> > >
> > > Please, could you enlighten me once more?
> > >
> >
> >Yeah, syncookie in the kernel 2.2.x can help tcp connection avoid syn
> >flooding attach, I mean that it is work on the TCP layer. However, IPVS is
> >working on IP layer, each entry (marking connection state) need 128 bytes
> >effective memory. Random Syn-drop is to randomly drop some syn entry
> >before running out of memory. It may help IPVS box survive even under a
> >big distributed syn-flooding attach, but real servers still need setup
> >syncookie to prevent themselves from syn-flooding attack.
> >
> > >
> > > BTW.: What are the plans for transfering the ip_vs_masq_table from one
> > > kernel to another one in case of a failover of the loadbalancer? Is
> > > there already some idea or whatever?
> > >
> >
> >I just thought an idea on transfering the state table, it might be good.
> >We run a SendingState and a ReceivingState kernel_thread (daemons inside
> >the kernel like kflushd and kswapd) on the primary IPVS and the backup
> >respectively. Everytime the primary handles packets, it will put the
> >change of state in a sending queue. The SendingState kernel_thread will
> >wake up every HZ or HZ/2, to send the change in the queue to the
> >ReceivingState kernel_thread through UDP packets, and clear the queue
> >finally. The ReceivingState receives the packets and changes its own state
> >table.
> >
> >Since all is inside the kernel, it should be efficient, because the
> >switching overhead between the kernel and the user space (both for the UDP
> >communications and the read & write of those entries) can be avoided.
> >
> >Any comments?
>
> By the time the LVS box needs to fail-over, the state of the failing kernel
> can not be trusted. So send the state to other LVS box may not get correct
> data and cause more problem than help. It should not have kernel involved
> at all. Just my 2 cents.
>
>
> >Thanks,
> >
> >Wensong
> >
> >
>
>
>
|
