LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] realserver to vip connections discussion, WAS: RE: lvs-

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] realserver to vip connections discussion, WAS: RE: lvs-users Digest, Vol 89, Issue 3
From: "Fred Clift" <fclift@xxxxxxxxx>
Date: Thu, 3 Jun 2010 10:46:42 -0400
There are at least two other ways to solve this, and I'm still working
on another more general solution.

0) the /etc/hosts (or split-horizon dns) solution talked about in the
thread.  Pros:  very simple to configure.  Cons: your realserver to vip
traffic is not load-balanced and your requests appear to not come from a
public ip (e.g. if you have two different sets of lvs services it may be
nice to have all traffic go between the two services vips e.g. vip to
vip traffic.)

1) on each realserver you have, put a pair of firewall rules that look
something like this:
--------------------------------------
#clear the table
iptables -t nat -F

#inbound
iptables -t nat -A POSTROUTING  -o <whatever interface> -s
10.115.50.51/32  -j SNAT --to-source 168.2.2.181
iptables -t nat -A POSTROUTING  -o <whatever interface> -s
10.115.50.53/32  -j SNAT --to-source 168.2.2.186

#outbound
iptables -t nat -A PREROUTING -i <whatever interface> -d 168.2.2.181/32
-j DNAT --to-destination 10.115.50.51
iptables -t nat -A PREROUTING -i <whatever interface> -d 168.2.2.186/32
-j DNAT --to-destination 10.115.50.53
-----------------------------------------


If you put this on both realservers, then the client can connect to the
vip of the destination and it's connection appears to come from the vip
of the client.  You'll need a pair of rules for each realserver - this
is the simple case of one realserver per service...  You may not need
the interface specifiers for your setup (I do because the servers are
multi-homed and have a separate interface for san traffic...


Pros:  traffic appears to come from the right place, no DNS fiddling
needed  Cons:  Since the traffic doesn't go through the director, no
loadbalancing is done, though you might be able to fake it with firewall
rules...  

2)  don't set your default route to be the director "nat_router" ip.
Instead set it to the IP of a different linux box that is set up to
route packets, turn on ip_masq or put in static nat rules on that box.
Then, all lvs traffic will traverse the proper route (e.g. responses to
external-from-the-internet connections) but any connections originating
from your realservers will go out the separate default route, get masq'd
to the ip of the secondary router, and then will get forwarded to the
director like any other traffic destined for the vip.  In essence, you
use a different outbound router to force the connections to go through
the public front end of your director.

Pros:  all traffic goes through the right LB rules on the director.
Cons:  all traffic appears to come FROM the ip of the router.  The
router is not HA, like if you used the nat_router on a pair of directors
so you have a single point of failure - if this secondary router is
down, all your local connections will fail.


I've verified that all 3 of these solutions work when using LVS-NAT.  I
haven't thought how they would work with DR at all.  I've been meaning
to write up a detailed explanation of these for a few weeks, after
several people on the list gave me good ideas and pointers.  I guess
this will have to do :)

Fred Clift


>
> On Wed, 2 Jun 2010, Charl Oswald Young wrote:
>
>> Now the problem I'm having is when trying to call a URL (for which
the
>> domain points to my LB IP) from behind the LB the request times out.
>



This email message is intended for the use of the person to whom it has been 
sent, and may contain information that is confidential or legally protected. If 
you are not the intended recipient or have received this message in error, you 
are not authorized to copy, distribute, or otherwise use this message or its 
attachments. Please notify the sender immediately by return e-mail and 
permanently delete this message and any attachments. Verio, Inc. makes no 
warranty that this email is error or virus free.  Thank you.

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

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