|
On Wed, Dec 07, 2011 at 08:54:20AM +0000, Dean Scothern wrote:
> 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.
My opinion is that the Masq behaviour is a desirable new feature
and I will be reticent to remove it in the future.
> 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?
I believe that I also observed the behaviour above using a backport of
IPVS (~2.6.36 code) to the 2.6.35.4[*] kernel, though the reason for the
backport was to test an unrelated feature (SNAT). The reason for the
backport being that I was not able to upgrade the entire kernel.
So I suspect that you could build an updated IPVS module for centos6,
either backporting IPVS in its entirety or just the changes that you are
interested in. But doing so is a somewhat involved process, by which I
mean, if you haven't done something like that before then be prepared
for it to take a bit of time.
[*] For reference, the backport is available in the
v2.6.35.4-ipvs-backport branch of my IPVS tree on Kernel.Org
git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs.git
I just uploaded it there as I only recently had my access to kernel.org
restored after the break-in they experienced. The same tree is also
available on github, which I was using as a temporary home
until my account was restored.
git://github.com/horms/ipvs.git
Looking over the backport it seems that the following patch is relevant
https://github.com/horms/ipvs/commit/c123e9ff994388b21b507d4f0377a425b76bcc02
I'm unsure if that is all that is necessary,
though I do recall some subsequent fixes for corner cases.
In any case, that patch explains why we see Route instead of Local.
It is intentional and Local can be explicitly set from user-space
(by enhancing ipvsadm) if needed.
_______________________________________________
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
|
