|
On Tue, Nov 29, 2011 at 01:13:01PM +0000, Dean Scothern wrote:
> Hi,
>
> Is there a way to either disable or bypass the localnode behaviour in
> ipvs?
>
> I'm trying to build a simple 2 node mail load balanced cluster. I have a
> mail server on each node and load balance between the two via a vip. I'm
> not allowed to use the lvs-dr method as our network guys say that
> asynchronous routing is forbidden by our firewalls.
>
> I can use lvs-nat, with a separate 'back-end' network between the two
> machines. However the localnode behaviour forces the mail server (exim)
> to listen on the vip. When the second node's mail server is migrated to
> the first node (pacemaker), it cannot be accessed as all connections go
> to the vip and hence the first mail server.
>
> It appears that there was some experimentation to address this some years
> ago, but I'm not sure if there have been any recent developments.
> Apologies if this is a common question.
Hi Dean,
I should rummage through the changelog to see what has happened
but I noticed during recent testing that I can't actually
use the Local forwarding mechanism at all with recent (e.g. 3.1) kernels.
I'm unsure if this is a problem in general, but I believe it
does allow your use case to work if you use the masq forwarding mechaism.
I just tested the following:
# ipvsadm -C
# ipvsadm -A -t 10.3.3.134:80
# ipvsadm -a -t 10.3.3.134:80 -r 10.0.0.1:80 -m
# ipvsadm -a -t 10.3.3.134:80 -r 10.0.0.2:80 -m
# ipvsadm -a -t 10.3.3.134:80 -r 10.0.0.2:81 -m
# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.3.3.134:80 wlc
-> 10.0.0.1:80 Masq 1 0 0
-> 10.0.0.2:80 Masq 1 0 0
-> 10.0.0.2:81 Masq 1 0 0
Note both the 81 and Masq. I believe that these are signifiant to this
discussion.
I then ran three daemons (netcat), on on each of 10.0.0.1:80, 10.0.0.2:80
and 10.0.0.2:81. It appears that connections to 10.3.3.134:80 are
load-balanced to the three daemons.
I did find that in the case where -m wasn't specified the Route (not Local)
forwarding mechanism was used and it seems to be necessary to use the VIP
as the realserver address in that case. Route (and Local and Tun) don't
allow port mapping, so port 80 was used in that case.
# ipvsadm -C
# ipvsadm -A -t 10.3.3.134:80
# ipvsadm -a -t 10.3.3.134:80 -r 10.3.3.134:80
# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.3.3.134:80 wlc
-> 10.3.3.134:80 Route 1 0 0
I would expect to see Local here instead of Route.
But I don't think that either is particularly useful to you.
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
