|
Hi guys
On Fri 20 Jan 2006 14:08:45 GMT , Joseph Mack NA3T <jmack@xxxxxxxx> wrote:
<snip docs comments and Joe's time-related problems...>
This sounds a neat trick. I'll wait for Graeme's reply before
updating the HOWTO.
Hrm.
I haven't tried any of this as I have a production cluster and no
current "test" system, so this is my opinion rather than an empirical,
measured response...
Assuming a simplified NAT layout as follows:
VIP1
Director DIP1 external
Director DIP2 internal
|
------------------------
| |
Realserver RIP1 Realserver RIP2
It's well-known that the realservers cannot communicate with the
director using VIP1 as their connection endpoint because the three-way
handshake never completes (packets arrive from DIP2 rather than VIP1 in
response to requests from a RIP).
I postulated an idea way back last year sometime:
http://marc.theaimsgroup.com/?l=linux-virtual-server&m=111057345213523&w=2
which someone then followed up with a successful implementation:
http://marc.theaimsgroup.com/?l=linux-virtual-server&m=112362236023899&w=2
(follow the thread).
What you've suggested is the "single VIP" case of the above idea. It
worked for me, it seems to have worked for Rob Wilson, so casting aside
the fact that you might have multiple VIPs frontending multiple
realserver clusters (as is my case) I can't see any reason why you
shouldn't just go for it.
In the case of LVS-NAT, the ARP problem simply doesn't exist because
the director is forwarding packets to the RIP and not the VIP; local
connections to the VIP from a realserver will be handled by that
realserver on the VIP alias and will therefore stay local; the only
issue I can see with ARP is if you have any sort of monitoring widget
with a view of both the NAT network and the "client" (or external)
network. If that proved to be a problem, then applying the same "fixes"
for the ARP problem as in DR will apply (and won't affect any other
aspects of operation).
To summarise: it should work. Suck it and see ;-)
Graeme
|
