|
At my organization, we are doing something very similar to this, but we are
going from LVS-TUN to LVS-DR to Real Server using firewall marks:
Client --> LVS-TUN --> LVS-DR --> Real Server --> Back to the Client.
This configuration forced us to configure LVS in a strange way. We basically
needed a dedicated "remote delivery address" as we called it.
Incoming traffic that is destined for the Real Server is firewall marked.
The LVS-TUN server then forwards the traffic to the LVS-DR server using a
dedicated address just for this communication. That server, de-capsualtes
it, and then forwards it to the Real Server, which then replies to the
Client.
Here is what our ldirectord looks like (very simplified):
On the LVS-TUN server 10.0.0.1:
virtual = xx
real = 10.0.0.2 ipip 1 (i.e the LVS-DR server)
protocol = fwm
On the LVS-DR server 10.0.0.2
virtual = xx
real = 10.0.0.3 gate 1 (i.e. the Real Server)
protocol = fwm
The Real Server of course runs 10.0.0.1 on the loopback interface.
What we're really accomplishing here is if a request comes into a data
center, but another one of our data centers is closer to the client who made
the request, we redirect that traffic to the other data center. Requests are
small, but replies are large, so this works for us. I've tried to simplify a
complicated setup above, so let me know if it's not clear. I think that you
should be able to accomplish the same using LVS-NAT.
On Fri, Aug 5, 2011 at 1:48 PM, Dave Porter
<dporter@xxxxxxxxxxxxxxxxxxxxx>wrote:
> Hey guys,
>
> I'm sure someone has run into this before, but I couldn't find anything
> searching.
>
> I'm trying to build a Load Balancer to several Load Balancer configuration
> - I'm using ldirectord for configuration.
>
> eg.
>
> Global Loadbalancer GVIP --> Regional LoadBalancer RVIP --> Real Servers
> RIP
>
> 10.116.3.10 --> 10.116.4.11 --> 192.168.1.1
>
> I'm using LVS-Tun (ipip) from the Global to the Regionals, then the
> Regionals run masquarading to the Real Servers.
>
> The issue I'm seeing is that the LVS at the regionals only listens on the
> RVIP:port it owns, and in order to service the Global VIP, it needs to
> listen on the Global VIP:port as well as the RVIP:port
>
> In other words, the regional load balancer listens on
> 10.116.4.11:80<http://10.116.4.11/>(and needs to for the health checks to
> work from the global), but packets
> arrive from the global with destination 10.116.3.11:80<http://10.116.3.11/>-
> these are ignored by the regional as there is no 'application' listening
> there.
>
> I can solve the issue by tunnelling the GVIP:port combination to the
> RVIP:port within the Regional box itself, but this seems a bit of a messy
> solution?
>
> Is there a nice neat solution for this ?
>
> Thanks !
>
> Dave Porter
> dporter@xxxxxxxxxxxxxxxxxxxxx
>
>
> _______________________________________________
> 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
>
_______________________________________________
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
|
