On Thu, Nov 10, 2011 at 03:14:44PM -0400, mike wrote:
> > On 11-11-09 09:33 PM, Simon Horman wrote:
>> > >On Wed, Nov 09, 2011 at 12:18:22PM -0400, mike wrote:
>>> > >>Thanks Nick:
>>> > >>
>>> > >>Here's the config that is the issue right now:
>>> > >>#SERVER1.vip.intranet.mydomain.com
>>> > >>virtual=172.28.191.194:8080
>>> > >> protocol=tcp
>>> > >> scheduler=lc
>>> > >> checktype=connect
>>> > >> checkport=8080
>>> > >> #negotiatetimeout=10
>>> > >> real=172.28.191.170:8080 masq
>>> > >> real=172.28.191.171:8080 masq
>>> > >> #service=ldap
>>> > >> protocol=tcp
>>> > >> checktimeout=10
>>> > >> checkinterval=10
>>> > >>
>>> > >>#SERVER2.vip.intranet.mydomain.com
>>> > >>virtual=172.28.191.155:8080
>>> > >> protocol=tcp
>>> > >> scheduler=lc
>>> > >> checktype=connect
>>> > >> checkport=8080
>>> > >> #negotiatetimeout=10
>>> > >> real=172.28.191.139:8080 masq
>>> > >> real=172.28.191.140:8080 masq
>>> > >> protocol=tcp
>>> > >> checktimeout=10
>>> > >> checkinterval=10
>>> > >>
>>> > >>So traffic comes in to 155 on Blade A or B depending on which LVS
>>> > server
>>> > >>s primary, gets "sprayed" to 139/140 on Blades A,B
>>> > >> From 139/140 on Blade A or B it goes to 194 on Blade A and gets
>>> > >>"sprayed" to 170/171 on Blades A,B
>>> > >>(FWIW, I didn't design this mess, in fact I argued vehemently against
>>> > it
>>> > >>and lost so it is what it is.)
>>> > >>
>>> > >>Summary:
>>> > >>Request ----> 155 LVS (Blade A or B)
>>> > >>----> 139/140 (Blade A or B)
>>> > >>----> 194 LVS (Blade A or B)
>>> > >>-----> 170 Blade A /171 Blade B
>>> > >>
>>> > >>The problem arises when traffic is routed from 194 on Blade A to 170 on
>>> > >>Blade A. It hangs. If it goes to 171 on Blade B, it works.
>> > >Hi Mike,
>> > >
>> > >I believe that you will need to use SNAT on at least the 172.28.191.194
>> > >virtual service as it is connected to by realservers. This is to
>> > >ensure that return packets from 172.28.191.170,171 go via 172.28.191.194
>> > >rather than directly back to 172.28.191.139,140.
>> > >
>> > >SNAT support was added to LVS in the 2.6.36 kernel.
>> > >Loadbalancer.Org have an overview of how it may be used:
>> > >http://blog.loadbalancer.org/enabling-snat-in-lvs-xt_ipvs-and-iptables/
>> > >
> > So something like this then Simon?
> > /usr/local/sbin/iptables -t nat -A POSTROUTING -m ipvs --vaddr
> > 172.28.191.170/24 --vport 80 -j SNAT --to-source 172.28.191.194
> > /usr/local/sbin/iptables -t nat -A POSTROUTING -m ipvs --vaddr
> > 172.28.191.171/24 --vport 80 -j SNAT --to-source 172.28.191.194
I wonder if, as in your set up the VIP and DIP[1] are the same address,
the following is what you need.
/usr/local/sbin/iptables -t nat -A POSTROUTING \
-m ipvs --vaddr 172.28.191.194/24 --vport 80 \
-j SNAT --to-source 172.28.191.194
/usr/local/sbin/iptables -t nat -A POSTROUTING \
-m ipvs --vaddr 172.28.191.194/24 --vport 80 \
-j SNAT --to-source 172.28.191.194
[1]http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.introduction.html#nomenclature
You will also need to make sure that the conntrack facility of IPVS is
enabled.
echo 1> /proc/sys/net/ipv4/vs/conntrack
My recollection is that this tuning parameter did not exist when SNAT
support was first added, and that it was always on. Off the top of my head,
I recall that the proc entry was added in 2.6.37. In any case, if it is
present you should enable it in order to use SNAT. Otherwise the iptables
rules will not match any packets.
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
