CSS loadbalancing based on a string in the URL

wassim.sharbek · ‎07-16-2010

Hi guys,

I have CSS11503 running 08.10.1.06 and I’m trying to configure loadbalancing based on a string in the URL. Our goal is that the CSS will forward a customer request to the same server always depending on a unique customer ID found in the URL, and without using the sticky table. I have build the config below to perform the following, but it seems not function as expected:

Assuming customers will use the links below:

http://10.1.1.30:8080/opensso/subjectid2w2w2w2wxzxzxzxzxzxz

http://10.1.1.30:8080/opensso/subjectid12345678asasasasasasasasas

1- CSS will take a string from the 1^st to 100 character out of the URL after the "/opensso/

2- CSS will look for the string prefix (subjectid),

3- CSS will pick up a 8 bytes string right after the prefix (subjectid) to apply the URL advanced load balancing. For example: CSS will depend on the string (user ID) “2w2w2w2w” from the first user’s URL above, and send the request to a server. Next time when the user sends a request to the CSS, the request will be sent to the same server because it always include the same user ID ““2w2w2w2w” after the prefix (subjectid) for that user.

I notice this is not functioning as expected. When I do continues test ( keep refreshing my browser to go to the mentioned URL) the CSS directs the request to the same server. If I stop testing for few minutes, or If I clear my browser cash, the CSS directs all requests to the other server even I’m not changing the URL.

Any idea if I'm missing anything in the config?

Considering the following:

-We don’t want a loadbalancing solution based on cookies. Our customers may clear the cookies at anytime, or they don’t want to accept cookies.

-I’m wondering about the difference between “balance urlhash” and “advanced-balance url “?

With “balance urlhash”, will the CSS hash the whole URL, or we can configure the String parameters so the CSS will hash only 8 bytes after the prefix (subjectid) in my configuration?

!*************************** OWNER ***************************

owner Test-SSO

content 8080

vip address 10.1.1.30

add service test.sticky.app1.sso.int-8080

add service test.sticky.app2.sso.int-8080

advanced-balance url

string process-length 8

string prefix "subjectid"

protocol tcp

port 8080

url "/opensso/*"

active

service test.sticky.app1.sso.int-8080

ip address 10.1.1.31

port 8080

keepalive http-rspcode 302

keepalive type http non-persistent

keepalive port 8080

protocol tcp

keepalive uri "/opensso"

active

service test.sticky.app2.sso.int-8080

ip address 10.1.1.32

port 8080

keepalive http-rspcode 302

keepalive type http non-persistent

keepalive port 8080

protocol tcp

keepalive uri "/opensso"

active

Thanks

Gilles Dufour · ‎07-19-2010

The CSS does not learn any cookie or url string.

It only does a hash of the value and send the same hash to the same server.

The problem is that since we do not learn anything from the server response, there is no guarantee that the first request (which does not contain the url stiky info) and the subsequent requests (which do contain the sticky info) will go to the same server.

In other words, the first request for "www.mysite.com/" goes to server A because the CSS didn't see any sticky info and just did some random loadbalancing. The response from the server contains links with www.mysite.com/....sticky_info.....

This time the request contains the sticky info, we do hash a decide this hash is associated to server B.

ll requests from this client will now be sent to serverB...unfortunately this is not the same as the initial server.

There is nothing you can do about this.

The best way to do stickyness on the css for http traffic is arrowpoint cookie.

Gilles.