|
First of all, I am currently using two CISCO Local Directors that load
balance to my real servers. Each Local Director is on its own network and
each real server has two interfaces, one to each Local Director. We're
doing this for network resilience-sake. A client goes to DNS and DNS
returns an address of one of the two Local Directors. The client then
connects to a Local Director and the Local Director picks a real server to
route to. The client's connection remains indefinitely. We have thousands
of clients, however, and DNS issues addresses of the two Local Directors in
a round-robin fashion. Client connections are, therefore, load-balanced
across the Local Directors and real servers. Here's the problem... Once
packets reach a real server how would the real server return the packet to
the correct Local Director that it came from?
I'm wanting to replace the CISCO local directors with Linux Directors (LVS
on Linux). In my testing of this I've tried using IPCHAINS to MASQ the
source address in the forward chain on the Linux Director. Yet I found that
packets don't even go through the forward chain on the Linux Director. I
then studied and tried using IPROUTE2. This worked on a client-by-client
basis. In other words I'd have to have an 'ip rule' for each client that
connects through the Linux Director - a potential of thousands of 'ip rule'
entries.
Joe Mack and Keith Barrett were very helpful to me!! Joe suggested that I
put a NAT router in front of the Linux Directors that would MASQ the source
address on inbound packets. This would require me to add only two static
routes in my real servers to return packets to the NAT router using the
'correct' Linux Director as a hop. THIS WORKS, and works well. Thanks Joe
Mack!
However, I'm still interested in how to do all of this in the Linux
Director.
You wouldn't believe this, but how we're doing it today - returning the
packets from the real servers to the correct Local Director requires a
patch in the IP stack of each real server to simply return the packet based
on the interface it came in on. Pretty bad, eh? This is why I'm so
interested. Plus, we've had problems with... oh, never mind. Below is the
current diagram...
Clients on Outside Network
|
ISP
|
Firewall DNS
| |
10.1.1.0/24 | |
|----------------------------------------------------------------------------------|
| |
| |
Router Router
| |
10.1.51.0/24 10.1.52.0/24
|--------------------------------------|
|-------------------------------------|
| |
10.1.51.1 10.1.52.1
Local Director Local Director
10.1.51.2 10.1.52.2
| |
| |
|----------------------------------------------------------------------------------------------------------------------|
| |
|
|---------------------------------------------------------------------------------------------------------------|
| |
| |
Real Server Farm
Sorry for such a verbose writeup.
Bobby Moore Worldspan
Phone: 770.563.7362 Fax: 770.563.6406
bobby.moore@xxxxxxxxxxxxx
Julian Anastasov
<uli@xxxxxxxxxxxxx To: bobby.moore@xxxxxxxxxxxxx
a.acad.bg> cc: Michael Burschik
<burschik@xxxxxxxxx>,
lvs-users@xxxxxxxxxxxxxxxxxxxxxx
05/12/2000 09:11 Subject: Re: LVS using NAT
and several routers
AM
Hello,
On Fri, 12 May 2000 bobby.moore@xxxxxxxxxxxxx wrote:
>
> How would you do it if your real servers can't policy route (route based
> upon source address)?
>
Do you have such problem?
I can do it without policy route! Tell me how do you split
the requests and I will tell you how to do it without policy routing!
It depends on the way the requests are selected. It depends on
the used topology. Or may be not?
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|
