ACE cookie-based slb

[UHansen1976]

Hi,

I'm trying to configure a cookie-based slb method which corresponds to my current CSS11503-configuration. Basicly, my CSS performs slb purely based on the content of the arrowpoint-cookie, using the following config:

advanced-balance arrowpoint-cookie
arrowpoint-cookie name WPS6

The cookie contains the real ip of the underlying webserver and the CSS fowards traffic based on that particular content of the cookie. Whenever we need to do an unscheduled shutdown of a webserver, we gracefully take the webserver out of service by setting the weight to 0, but also, my webdepartment have implemented a feature in Websphere, that somehow sends a cookie-expire to both the SESSIONID-cookie and the WPS6 cookie. So once the subsequent http-req hits the CSS, the cookie is gone and the CSS lb'es the req to a diffent server. We've intentionally left out the sticky-option, as it didn't work well with the before mentioned Websphere-feature.

Now I'm trying to configure something similar on the ACE, but so far without luck. I did start by configuring sticky-group with the cookie-insert option and a http-parametermap with persistence-rebalance. But all attempts to recreate the above mentioned scenario, have failed. It's seems, that even with persistence-rebalance, the client-session is still stuck to the webserver and a display of the sticky-database shows, that the sticky-entry persists. Even when I manually delete the cookie-container on the client and verify with the Live-HTTP-plugin, that the subsequent http-req does not contain the WPS6 cookie, the req is still forwarded to the realserver. Even when the real-server is placed in 'inservice standby'.

Is it possible to staticly define a cookie-value for, say, 4 webservers, each with their own unique cookie? And when the initial part of the tcp is completed and the ACE decides which realserver is to be used, it sets a cookie containing that particular value and includes it in the http-response. So if any subsequent http-req's are not containing that cookie, the ACE re-balancences that req and sends it to a different webserver.

/Ulrich

PS! Merry X-mas

[Gilles Dufour · Accepted solution]

Ulrich,

what you're asking for is what ACE does currently.

The static cookies are created at configuration time.

You can see the values with "show sticky cookie-insert"

ie:

switch/Admin# show sticky cookie-insert group portalap
     Cookie   |        HashKey       |           rserver-instance
  ------------+----------------------+----------------------------------------+
  R4181073320 | 11105909834649097754 | vmware-http/vmware-27:80
  R4181109257 | 10017312105356339124 | vmware-http/vmware-28:80
  R4183409225 | 15537882249682767338 | vmware-http/vmware-46:80
  R4183517036 | 1787657754489574767  | vmware-http/vmware-49:80

Whenever we see the cookie "R...." we check if the associated server is alive and forward the connection to that server.

Otherwise we loadbalance to a new server and include the new cookie in the response.

For established connections, persistence rebalance is indeed required to inspect every request and rebalance the connection to a new server if a new cookie is detected.  However ACE will try not to rebalance when not needed.

If you need a new loadbalancing decision each time, you need 'persistence rebalance strict'.

An alternative could be the configuration of 'failaction purge' to force the connection to be terminated when the server goes down.

'inservice standby' is described @ http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/rsfarms.html#wp1000333

•Tears down existing non-TCP connections to the server

•Allows current TCP connections to complete

•Allows new sticky connections for existing server connections that match entries in the sticky database

•Load balances all new connections (other than the matching sticky connections mentioned above) to the other servers in the server farm

•Eventually takes the server out of service

As you can see, this option still allows connection to the server if it matches a sticky entry.

Gilles.

[UHansen1976]

Hi Gilles,

I'll give the 'failaction purge' a try. But I did try to include a persistence-rebalance parmmap in my policy-map and thought, that if I deleted the client's cookie containing the R......-value, the ACE would rebalance the subsequent request. But my webappl. programmer produced a trace, in which he proved me wrong.

Furthermore, you wrote:

"Whenever we see the cookie "R...." we check if the associated server is alive and forward the connection to that server.

Otherwise we loadbalance to a new server and include the new cookie in the response."

So even if the rserver is in 'inservice standby' mode, the ACE somehow checks if the server is actually responsive? Does it use the associated probe for that?

In regards to the absence of the R-cookie. We did a test, where we performed the initial request and verified, that the ACE performed it's lb-algo and produced a cookie containing the R-value and this was consistent with the entry in the sticky-db. Subsequently, we manually deleted the cookie in the clients browser (both IE7 and FF3.5) and verified that the next http-req did infact not contain the R-cookie. But even so, and with persistence-rebalance, enabled, the HTTP200 reply to the client contained the exact same cookie-value. And prior the that, we had placed the rserver in 'inservice standby' mode.

Of course, all this might be caused by a misconfiguration on my part, and furthermore, at no point was the rserver actually unresponsive. So if the ACE somehow uses another kind of logic to check, if the rserver matching the sticky-entry is still alive, I guess it's only doing what we're asking it to do.

I'll do some more testing and see where it leads me.

Thanks for your reply and I wish you happy holidays.

/Ulrich