|
> I've checked the mailing list and persistence paper, and it seems the
thing
> to do is to adjust the persistence granularity . However , if I adjust the
> netmask, all of our internal network traffic will go to one server , which
> kind of defeats the purpose.
>
We're having the exact same problem with WebSphere cookie-based sessions. I
was testing this earlier today and I think I've solved this particular
problem by using firewall marks.
Basically, I'm setting everything from our internal network with one FWMARK
and everything else with another. Then, I setup the ipvsadm rules with the
default client persistence for our internal network(/32) and a class C
netmask granularity (/24) for everything from the outside to deal w/ the AOL
proxy farms.
Here's the iptables script I'm using to set the marks:
iptables -F -t mangle
iptables -t mangle -A PREROUTING -p tcp -s 10.3.4.0/24 -d $VIP/32 --dport
80 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p tcp -s ! 10.3.4.0/24 -d $VIP/32 --dport
80 -j MARK --set-mark 2
Then, I have the following rules setup for ipvsadm:
ipvsadm -C
ipvsadm -A -f 1 -s wlc -p 2000
ipvsadm -a -f 1 -r $RIP1:0 -g -w 1
ipvsadm -a -f 1 -r $RIP2:0 -g -w 1
ipvsadm -A -f 2 -s wlc -p 2000 -M 255.255.255.0
ipvsadm -a -f 2 -r $RIP1:0 -g -w 1
ipvsadm -a -f 2 -r $RIP2:0 -g -w 1
FWMARK #1 doesn't have a persistent mask specified, so each client on the
10.3.4.0/24 network is seen as an individual client. FWMARK #2 packets are
seen as a class C client network to deal with the AOL proxy farm problem.
Like I said, I just did this today, and based on my limited testing, I think
it works. I'm thinking about maybe setting a whole bunch of rules to deal
w/ each of the published AOL cache-proxy server networks
(http://webmaster.info.aol.com/index.cfm?article=15&sitenum=2), but I think
that would be too much of an administrative nightmare if they change it.
> What I'm concluding is , that I'll need to change the network architecture
(
> since we are all on one subnet ) , or buy a load balancer which will look
at
> the actual data in the packets ( layer 7 ? ) .
>
I'd still like to see this. The ktcpvs project implements some level of
layer-7 switching by matching URL patterns, but we need the same type of
cookie based persistence for our WebSphere real servers. Hopefully, it
won't be too long before that gets added.
Chris
|
