|
Hello,
On Fri, 12 May 2000 bobby.moore@xxxxxxxxxxxxx wrote:
>
> 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
Did you tried something like this:
ip rule add prio 100 from RIP1 iif lo table 100
ip rule add prio 101 from RIP2 iif lo table 101
ip route add table 100 0/0 via DIP1 dev eth0
ip route add table 101 0/0 via DIP2 dev eth0
By this way each MASQ router can work with any
real server even on one eth0 media. The real server selects
the gateway based on the saddr in the packet.
> 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.
Are the above rules correct?
>
> 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.
Good picture. I like pictures.
If you don't want Direct route mode you have these variants:
- with above rules (you can tune them) each MASQ router can work
with any real server
- if you can't use policy routing in the real servers you have to
split the real servers in two clusters. This should not be a
problem for you. Each real server will use one masq router as a
gateway. Sorry! If you have 4 real servers, 2 will use router1 and
2 will use router2 as def gw.
If you can live without the MASQ mode of LVS you can
try Direct routing mode. In this mode your real servers are free
to use any router for the outgoing traffic. The other question is
what happens when this outgoing router is dead.
This is the reason I recommended to you the variant with
the policy routing. Because if one director blocks, the requests come
from the other and the replies return again through the working router.
Each router demasquerades to different RIP in each real server.
I assume your goals are:
- to support many running directors
May be your routers die often?
- to rely on MASQ for your firewall
There are many variants for setups with different
restrictions. I can't comment why you use such topology because
I don't know the parameters for your ISP: bandwidth, what is
your incoming and outgoing traffic. These games with the DNS
don't allow persistent services to work as expected. So,
it depends what services you have. I can only show you some
solutions (some of them I have never tried). But you decide :)
Don't forget that even in Direct route mode you can
make visible only the directors. The real servers will not
be reached from the world but they can send to the world!
The incoming traffic is routed from the directors. What
we have: again 2 hosts to protect!!!
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|
