|
greetings.
On Tue, 21 Nov 2000, John Lukac wrote:
>
> Hi there,
>
> I remember that while researching the DR method in the archives here a
> few days ago, I stumbled upon a letter which asked whether or not this
> direct routing method requires each real-server to have a "real ip" (as
> in routable, external, etc.) when used in a production environment --
> but I can't find the message and follow-ups anymore. So..
>
> The question: In a production environment, in order that DR work, does
> each real-server have to have it's own routable IP?
no. they can use internal unroutable ips.
i do this myself.
they real servers have to be on the same _physical_ network as the router
in front of the director, so the real servers can transmit back to the
router directly on the ethernet (or whatever physical medium i suppose)
level. then just make sure you have the network of the router on your
real servers, and the real servers' gateways set as the router's ip. you
may also have to add a static arp entry for the router/router's ip. this
has something to do with the router not being able to send arp responses
back to the real servers since the real servers have no ip on the network
the router is on. i'm not sure why the router would care about that
(maybe that's some sort of setting), but i've had to do this on my real
servers (i don't have access to the router to futz with that).
beyond that, everything else is the same for normal dr. ipvs rules on the
director, solving the "arp problem" on the real servers, and so on.
to me, this method seems like the best way to get the fastest response
times while not wasting public ip space.
> Based on all the examples I've been reading, it appears that this must
> be the case, as all the real-servers are on the same network as the
> director. The howto mentions "lars' method" (a possible solution to the
> arp problem) in which the real-servers are put on an "inside network,"
> and then use the director as a gateway (which seems to actually resemble
> a NAT network more so than DR!).
yeah, i don't think any of the examples in the howtos take this method
into account. it's not very common.
> The history: For starters, I setup a NAT system, but when I ran
> stress-tests on the system, devices on both the director and the
> real-servers were full of collisions (at least, according to ifconfig).
> I'm still a budding network admin, so these collisions leave me
> worried. So I attempted to setup a DR method, but found myself stuck at
> the "multiple external IP" part; I tried to go around this by using a
> cisco switch seperated into two vlans and having each machine (director
> and real-server alike) connect to both vlans. Wish I could ascii-ize
> the topology, but it's somewhat complicated (and my ascii skills leave
> something to be desired). The important part is that my setup didn't
> work for clients outside the VIP's netmask (the VIP is one of the
> external routable IP's). If it'd help, I can draw the topology on paper
> and scan it in..
>
> More history: I read some of tcl's correspondance, and I got the idea
> that I could just put everything on the same vlan on the switch, and use
> the ipchains' rules, but during the stress test, I had at least 2x more
> collisions (according to ifconfig), and observable response time was
> unforutnatley slow. Not to mention that the real-servers need to have
> the ability to sendmail out, and that only works by setting up them
> additional ip rule things (didn't have time to test it out).
i have no collision problems. are you sure you're preventing the arp
problem from surfacing? http://www.linuxvirtualserver.org/arp.html
> The why: According to some follow-ups I've read, it seems that the NAT
> method is the "correct" setup when the director is to act as the load
> balancer, firewall, and gateway for the internal machines. But I'd like
> to skip that final "unecessary" hop back through the director and just
> go directly through the isp's router. But then, I only have a few ip's
> from the isp. Gronk.
yeah, most people just do nat in a case like that. but the method that
i'm using (and possibly others) should work just fine given proper setup.
> I appreciate any comments, and feel free to poke fun at the learning
> network admin :)
> Jano
good luck.
-tcl.
|
