LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: question on faq 4.18

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: question on faq 4.18
From: Graeme Fowler <graeme@xxxxxxxxxxx>
Date: Fri, 20 Jan 2006 14:37:56 +0000
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


<Prev in Thread] Current Thread [Next in Thread>