|
On Fri, 15 Sep 2006, Per Jessen wrote:
That was also my first thought, but the docs on "the ARP problem" does
talk about both LVS-DR and LVS-TUN.
hmm. This is a holdover from my setups where I did
everything under my desk and changed from LVS-DR to LVS-Tun
and back without changing the network, and had to handle the
arp problem. When the realserver is on some other network,
you don't need to handle the arp problem. I will fix up the
HOWTO to make this clearer.
Yep, I've got a test-setup pretty much like that - one director, 4 real
servers. What I don't have are multiple networks,
Put the client and VIP on 10.0.x.x/24 and the realserver
RIPs on 192.168.y.y/24. You can have 1 or 2 NICs on the
director. You only need 1 hub/unmanaged switch for all the
cables. All machines can now see all packets, but this isn't
a problem. Make the client the default gw for the
realservers. Put a static arp entry in the client for the
VIP using the MAC address on the director. Ping the VIP from
the client, check that the entry in the arp table (arp -a)
is the one for the director (you may have to flush the arp
table first).
The objective of this exercise (in case anyone is interested) is to run
one or more LVS's, with the ability to add new servers more or less
on-demand. All servers will be leased in remote datacentres, and I was
hoping to avoid having to put too many restrictions on the networking
side. (makes it easier to work with the datacentre people).
you'll have to change their filter rules to allow packets
out that are coming from the VIP (which won't be in their
network).
Joe
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!
|
