LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: DR capabilities - not arp question :)

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: DR capabilities - not arp question :)
From: Horms <horms@xxxxxxxxxxxx>
Date: Sun, 30 Jun 2002 21:23:35 +0900
On Fri, Jun 28, 2002 at 02:46:18PM -0400, Ed Crotty wrote:
> > I have a fundemental question about the capabilities of DR.. We have
> > been happy users of LVS NAT for a couple of years but due to
> > bandwidth constraints, we need to reimplement our current strategy.  
> > 
> > I have a couple of questions about the DR implementation (no its not
> > about ARP :D)
> > 
> > Scenario - Today we have a fully, correctly functioning LVS setup.
> > It is NAT based.  It goes out to 4 bonded T1s.  Everything is happy.
> > 
> > Future   - We have an additional 2 T1s on a different network to the
> > ineternet that we would like to have all incoming traffic come down,
> > and push the outbound traffic out the 4 bonded T1s
> >  
> >       It seems to me that DR will be able to accomplish this.. Is
> >       this accurate?  Can the RS network be a private segment as
> >       long as it has VIPs for the virtual defined on the machine?
> >       The reason I ask is that we would like to do as little change
> >       to the network as               possible (if its not possible
> >       however, such is life!)
> >
> > 
> > Current LVS implementation
> > 
> > 
> >                     |                               
> >                     | internet (out to 4 bonded T1s)
> >             =========================
> >                     |                               |
> >             |       director                        |
> >             =========================
> >                     | private segment .1
> >                     |
> >                     |
> >             ------------------------------------- (10.1.1.0)
> >             |       |       |       |
> >             |       |       |       |
> >             RS1 .2  RS2 .3  RS3 .4  RS4 .5 
> >                     RS DG = 10.1.1.1
> > 
> > Possible DR implementation (?)

As far as the Linux Director is concerned this is fine.
However, when I tried a similar setup a couple of weeks
ago, with the VIP on lo:0 on each of the Real Servers
I ran into a problem. It seemed that the Real Servers
were not very happy about recieving traffic from the VIP's
network on eth0. I am pretty sure this can be resolved
with some /proc/sys/net tweaks but as I was not sort of
IP addresses - it was a test network - I didn't persue this
problem very far.

> > (note 2 T1s become incoming traffic points and 4 T1s become outbound 
> > traffic)
> >                       
> > internet (out to 4 T1s)     |                               
> >     |                       | internet (out to 2 bonded T1s)
> >     |               =========================
> >  ======     |                               |
> >  | FW |             |                       director                | 
> >  ======     =========================
> >     | .254          | private segment .1
> >     |                       |
> >     |                       |
> >     --------------------------------------------------------- (10.1.1.0)
> >             |       |       |       |
> >             |       |       |       |
> >             RS1 .2  RS2 .3  RS3 .4  RS4 .5 
> >             RS DG       = 10.1.1.254        
> > 
> > Will this scenario work?  Both the 4 T1s and the 2 T1s have
> > different public network ranges as well...

This is really a question about asymetric routing. Traffic comes
in one way and out another. As long as your routing works this
shouldn't be a problem. 

More specifically, the Linux Director only cares about incoming packets
so the fact that replies go a different path is irrelevant to
its operation. The Real Servers should be more or less oblivious to the
fact that their incoming traffic has gone through the Linux Director.
And again, they shouldn't really care that traffic comes in one way and
goes out another - minor /proc/sys/net twidling not withstanding.

-- 
Horms
        


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