CSM-S sticky and persistent rebalance

[Jon Marshall]

Apologies if this is a rather basic question but we are having problems with stickiness on our CSM-S blades.

Attached is the config we are currently using. Stickiness works but the login page where you get redirected just hangs.

If i change "persistent rebalance" to "no persistent rebalance" then the login works fine but then their is no stickiness and nothing shows up in the sticky table.

What i don't understand is how persistent rebalance is related to stickiness. And why/how it seems to break the login.

Any insights/help would be much appreciated.

[Gilles Dufour]

Jon,

I'm not 100% sure here, but it seems like combining cookie and url-mapping in the same policy could be a problem [I would have to verify this in the lab to be sure].

What CSM version do you have ?

It seems like you want to stick only when going for a particular url, and not stick for the others.

This is what brings you this *special* config.

I think you are complicating the design here for no real benefit. Why not just stick to a server whatever the url ?

You should get exactly the same result in terms of load by just using stickyness for every url.

So, use a simplified config like this

vserver DEV-LOGIN-HTTP

virtual 10.181.120.199 tcp www

no persistent rebalance

serverfarm DEV-LOGIN-HTTP

sticky 120 group 10

inservice

Gilles.

[Jon Marshall]

Gilles

Thanks for the prompt response.

We are using SW 2.1(1) on the CSM-S.

I think the main problem i have is that the developers used to manage the load balancers and we used to use the CSS. They assure me that what they are trying to do worked fine with the CSS but we can't seem to get it working on the CSM-S.

What you suggest seems perfectly reasonable however so i think i'll have another chat with them.

Many thanks

[Gilles Dufour]

Jon,

I just verified in the lab and combining both url-map and cookie sticky does work.

So the problem might be different in your case.

The workaround would still be a valid solution.

If you don't want to use the workaround, we will need you to capture a sniffer trace of a connection and a 'sho mod csm x sticky group 10' before and after the test as well as a 'sho mod csm x vser name det' before and after the test.

Thanks,

Gilles.

[Jon Marshall]

Gilles

We tried your config out and it works fine and the devleopers seem to be fairly happy with it. I would still like to get to the bottom of it but on leave next week so might look at it when i get back.

Many thanks for all your help

Jon

[dcayer]

Hi Gilles,

My thought is that Jon's initial error was maybe caused by the fact that he had no default policy configured... (maybe the SAP application forced "GET" requests to other URL's not accounted for in Jon's maps)...

Could Jon's original *fix* using the "no persistance rebalance" be explained by the fact that this command forces the CSM to ignore all subsequent HTTP GET commands for an already "sticked" connection?

Thanks,

Daniel

[Gilles Dufour]

Daniel,

this is indeed a possibility. Your explanation is perfectly correct.

Thanks for sharing it with us.

Gilles.