CSS bad stickiness

[f.franceschini]

Hi all,

seems we have some problems with stickiness src-ip on a CSS 11506. 6 clients are calling 4 servers.

The four servers are balanced this way:

content Prodotti_9503

add service Prodotti_BEA_WLS_9501_1

add service Prodotti_BEA_WLS_9501_2

protocol tcp

port 9503

vip address 10.216.86.153

advanced-balance sticky-srcip

add service Prodotti_BEA_WLS_9501_206

add service Prodotti_BEA_WLS_9501_207

active

All the traffic goes to Prodotti_BEA_WLS_9501_1 regardless of the client source IP.

All the servers are active.

Do you think this is due to the limited number of clients (the clients are frontend web servers)?

Do you know how the CSS hashing algorithm works in detail?

Thanks in advance.

Fausto

[Gilles Dufour · Accepted solution]

try to do a 'sticky-purge all' from the debug mode (use the command 'llama' to enter debug mode).

See if it makes a difference.

If you enable a sticky table with one server active and later enable the other servers, you could end up in the situation that you have.

The number of clients is also important.

With very few clients (less than 10) you may not have perfect loadbalancing.

Gilles.

[f.franceschini]

Thanks Gilles,

at a further analysis I saw that the bad load distribution depends on the order the servers are started. You were right.

I set up a workaround using acl with prefer clause and stickiness enabled at the same time. This is not a real stickiness but will do.

Do you know if it's possible to have stickiness on SRC-IP and SRC-PORT?

Fausto.

[Gilles Dufour]

Fausto,

we don't have stickyness based on source IP and source port.

I don't see the use of making stickyness on source-port. A client will use a new source port for every new connections, so stickyness based on a source port will never work.

Gilles.

[f.franceschini]

Hi Gilles,

I thought that stickiness on SRC-IP DST-IP could overcome the limitation of having only few source ip addresses so resulting in a better lad distribution.

Thanks for yuor help

Fausto

[Gilles Dufour]

you can do SRC-IP & DST-PORT and this is ok.

[But not SRC-IP & SRC-PORT or SRC-IP & DST-IP.]

But if you are only testing one application and therefore 1 port, the problem of low number of clients is still there.

Gilles.

[bstuart]

I just upgraded from a set of 11800's to 11506's. I'm running 7.20 build 206. We are doing a data center migration so it was a perfect time to upgrade and break my load-balancing out between internal and external users.

We made the change two nights ago and I spent most of the next day and yesterday troubleshooting some css issues that cropped up. One was with our online bill payment app and the other an agent and reseller site. Both have standard port 80 URL's that then redirect to https for login. Both were configured for sticky-srcip-dstport and immediately began having issues. If you went to servers directly everything worked fine.

Because of the way the redirects are setup we had a hard time getting them working when the sites were first setup. The port 80 rule listens, hits a server then it redirects back to the VIP address and the port 443 rule then reflects it back to the server. After the migration it appeared that intermittenly users would be redirected back to a server that didn't know about their session and browser errors would occur. I was able to set both of those to use ssl session ID and it fixed the issue.

I have another application that seems to be doing something very similar but it has no ssl piece so advanced-balance ssl will do no good with that one. I'm still searching for a workaround.

If anyone here has any suggestions they would be greatly appreciated.

[dwolsefer]

How about advanced-balance arrowpoint-cookies. This lets the content rule stick the client to the server based on the unique service identifier information of the selected server in the ArrowPoint-generated cookie.