LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Infinetely scalable DR

To: Horms <horms@xxxxxxxxxxxx>
Subject: Re: Infinetely scalable DR
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Wensong Zhang <wensong@xxxxxxxxxxxx>
Date: Wed, 24 May 2000 08:39:31 +0800 (CST)


On Tue, 23 May 2000, Horms wrote:

> On Tue, May 23, 2000 at 04:16:33PM +0300, Julian Anastasov wrote:
> > 
> >     Hello,
> > 
> > On Tue, 23 May 2000, Lars Marowsky-Bree wrote:
> > 
> > > Good morning,
> > > 
> > > during my presentation about LVS at SANE2000, an attendee brought up
> > > the following suggestion:
> > > 
> > > Apparently, TCP/IP allows for the server to reply with a _different_
> > > source address then the one the SYN packet was send to, and establish
> > > the connection to that adress instead.
> > > 
> > 
> >     How is that possible. Is it explained in some rfc?
> > 
> > > What this implies is the following:
> > > 
> > > If DR is used to resend the first SYN packet to the real server A, and
> > > A establishes the connection to the client with one of its own
> > > addresses, the LVS is _not_ involved in any further communication
> > > between the client and the real server.
> > > 
> > > Advantages: - Infinetely scalable. The LVS only sees the first packet
> > > of every connection, instead of every incoming packet.  - Desireable in
> > > a failover setting. Since the LVS is only involved for establishing the
> > > connection, no established connections die on failover of the LVS box.
> > > - Implicitly solves the problem that the LVS box may not be in the
> > > return path with a DR setup, since it no longer sees a packet comeing
> > > from one of its locally bound addresses.
> 
> As an aside, this is analogous to the behaviour when the clients,
> and real servers are on the ssmae network and LVS/DR is used thanks
> to ICMP redirects. 
> 
> > > This appears to be supported by most all TCP/IP implementations. Does
> > > anyone know if this is true or not?
> > 
> >     Looking in the kernel source I don't see such possibility.
> > > 
> > > It appears to me, that if this IS true, and if it is supported by a
> > > wide enough range of networking equipment, this would totally rule ;-)
> > > I don't have my Stevens handy on the road though, so I can't check
> > > myself right now.
> > > 
> > > This would not even involve changing the DR code, but instead adding a
> > > special kernel patch on the real servers, which had to reply with a
> > > different address than the one the packet was send to.
> > 
> >     I see the benefits. But I can't believe :) More info?
> 
> If it is possible, it would need to be an option (possibly the default)
> as some applications require the return address to match the address
> that the connection was requested for. Well, I have been lead
> to believe that the Java security model requires this, but that is
> another can of worms in itself which is probably best left unopened.
> 

I think that in most TCP/IP implementation, each connection requires that
the return address match its request address, otherwise the connection is
broken.

However, ICMP redirect message might be a good idea. If ICMP redirect
message went directly to the client host, I think that we would use the
ICMP redirect message just like http redirects for load balancing. But, as
far as I know, ICMP redirect message is usually sent to intermediate
routers. I need check the kernel code how the ICMP redirect message is
used.

Thanks,

Wensong

> -- 
> Horms
> 
> 




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