|
On Wed, December 7, at 07:42 Simon Horman wrote:
>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.
Thanks Simon,
This is certainly interesting that the behaviour has changed though I'm not
sure if it's a bug somewhere or intended behaviour.
Whilst it is possible that I can get a 3.1 kernel running on my centos6 test
machines (I'm a bit rusty on this), it would be a difficult call to roll it out
on our production machines. A later update might also 'fix' the problem,
reverting the behaviour. I was originally thinking of trying dkms to update
ipvs but keep the standard kernel (not sure if that is practical). Has the ipvs
code changed much between the stock centos6 kernels and the 3.1 code or is the
behaviour change possible due to kernel changes? I've not looked yet, so
apologies for sounding lazy.
I wonder if there is a simple 'reverse fix' to the centos6 2.6.32 kernel that
I can apply to give the current 3.1 masq behaviour?
Best Regards
_______________________________________________
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
|
