|
On 1/20/06, Graeme Fowler <graeme@xxxxxxxxxxx> wrote:
>
>
> 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.
Right. In fact, after reading your solution again, I think your solution is
the more useful general case, where there may be an arbitrary number of
VIPs, RIPs, and groupings of real servers (which I don't need right now, but
I've realized I will need it down the road). I have some Alteons that call
these real server groups, not sure what the LVS equivalent is, but here's a
short illustration.
Assume 1 director, 3 VIPs, 4 RIPs on 4 real servers. Assume we have real
server groups (RG) RG1 (RIP1-2), RG2 (RIP3-4), RG3 (RIP1-4). VIP1 goes to
RG1, VIP2 goes to RG2, VIP3 goes to RG3.
In my solution, servers in RG1 can simply put VIP1 and VIP3 on dummy
interfaces, but for proxy requests they will only be able to talk to
themselves. They will not be able to talk to VIP2. All servers should be
able to talk to VIP3. Your solution solves this by using fwmark.
Am I correct on all of this?
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).
>
This is a fairly common problem with NAT in general that I have to deal with
a lot. Basically, the NAT box will not apply NAT rules for traffic
originating and terminating on the NAT box. I recall that one workaround
for this is to use the OUTPUT chain, I can't find the rules at present but
it seemed to work ok.
-J
|
