ACE howto: ¿Classic round-robin if cookie not present?

[rogelioalvez]

Hello team:

My server farm behind the ACE will be used for applications that may or may not send cookies.

So I have been asked to configure the ACE to be aware of a certain cookie in order to stick client to server as expected. In paralell, I have also been asked to execute a classic round robin algorithm if no cookie is present on the HTTP sessions.

Then my question is: ¿ will my ACE, configured with the "sticky http-cookie ..." command, default to a classical round-robin algorithm if no cookie is detected in the HTTP request from the client?

Your hints will be greatly appreciated.

Best regards, Rogelio

[Borys Berlog · Accepted solution]

Hi Rogelio

Yes, it should work like this , if cookie isn't found - L3/4 loadbalancing is done without creating or checking sticky entries.

[parveesm123 · Accepted solution]

Hi Rogelio,

As Borys mentioned , yes it do .

How classic http stickiness works is as follows

1) first request from client comes to the load balacer , if http stickiness is configured (whether active or passive) ,it looks for http header . If cookie value is  not present  it process the stickiness and load balancing predictor and stores the client in the sticky table

2) if cookie is present it bypasses this process (checking stickiness and loadbalance predictor ) and directly pass to the server which is there in the sticky table.

HTH,

Parves

[rogelioalvez]

Hello guys. Thank you for your kind answer.

So I would appreciate a brief check of the following commands that should do it (I am just sending the involved commands):

By the way, the customer told me that PHPSESSID is the cookie expected from each the real servers (¿is this OK? ¿Shouldn´t the servers send their own and different cookie????)

sticky http-cookie PHPSESSID STICKY_SERVERS
  timeout 720
  serverfarm REAL_SERVERS
  replicate sticky

policy-map type loadbalance first-match STICKY_SLB_LOGIC
  class class-default
    sticky-serverfarm STICKY_SERVERS

class-map match-all VIP-30
  match virtual-address 10.150.3.30 tcp eq www

policy-map multi-match CLIENT_VIPS

  class VIP-30
    loadbalance vip inservice
    loadbalance policy STICKY_SLB_LOGIC
    loadbalance vip icmp-reply active

[rogelioalvez]

Guys: I think I am missing something in my configuration...

Besides the load balancing selection based on cookies, my matching technique should also be based on cookies. ¿ Am I right?

[rogelioalvez]

hello Borys:

Thanks a lot for your answer. I would appreciate if you could check please if the sample commands I typed in a previous post will make it.

Idea is:

1. If HTTP session is cookie-based, the balancer will take care of the cookie and stick the client to the server that attended the previous session and sent the cookie to the client

2. If HTTP is NOT cookie-based, the balancer will execute a plain L4 (port based) balancing algorithm

Your kind answer will be greatly appreciated

[sesoerensen · Accepted solution]

Rogelio,

*/ Create a http parameter-map, if you did not do so already:

parameter-map type http HTTP

  case-insensitive

  persistence-rebalance

  set header-maxparse-length 65535

  set content-maxparse-length 65535

  length-exceed continue

*/ Match the cookie, and whatever value PHP created:

class-map type http loadbalance match-any PHPSESSID

  2 match http cookie PHPSESSID cookie-value ".*"

*/ Create a policy map, add the PHPSESSID class-map, and assign the sticky serverfarm.

*/ Assign your real servers to the default class (class-default)

policy-map type loadbalance http first-match STICKY_SLB_LOGIC

class PHPSESSID

  sticky-serverfarm STICKY_SERVERS

class class-default

  serverfarm REAL_SERVERS

*/ Add it to the service policy

policy-map multi-match CLIENT_VIPS

  class VIP-30
    loadbalance vip inservice
    loadbalance policy STICKY_SLB_LOGIC
    loadbalance vip icmp-reply active

    appl-parameter http advanced-options HTTP

Cheers mate,

Søren Elleby Sørensen

[rogelioalvez]

Hi Soren:

I opened another discussion, because I moved the concept to a test environment but it is not working properly. The discussion is called "Sticky session reset by ¿ACE or real server?"

Perhaps you could tell me what I am missing in the configuration...

Thank you very much for your patience.

regards, rogelio

[Borys Berlog · Accepted solution]

Hi Rogelio

Looks good for me. Regardgin

>Shouldn´t the servers send their own and different cookie????

Yes, but cookie value will be different, not the cookie name. Cookie name has to be the same, that ACE knows what to look for.

>Besides the load balancing selection based on cookies, my matching technique should also be based on cookies. ¿ Am I right?

Don't  think so, at least accordgin to your first post - your requests don't  have cookies from the very beginning and need to be balanced based on  L3/L4 info by simple round-robin. So, I don't think you need to match  cookies anywhere else than sticky group. And your config above looks  good.

Regardgin parameter map provded by Søren below. It's hard to say if you need it. E.g. persistence-rebalance will force ACE to inspect each HTTP request in TCP session, which isn't always needed. I'd recommend to try without it and see if it works as you want.

In addition, I don't think you need to have  such matching :

>class-map type http loadbalance match-any PHPSESSID

  2 match http cookie PHPSESSID cookie-value ".*"

From what I understand your config above looks fine.

[rogelioalvez]

Hy Borys.

Thank you very much for your detailed answer!!

By the way, I opened another discussion because I moved the concept to a test environment, but the browsers are getting reset (at least this is what I see on the browser). My new post is called: "Sticky session reset by ¿ACE or real server?"

You are right with respect to the matching criteria. The clients do not send cookies from the very beginning.

Best regards, Rogelio

[Jorge Bejarano]

Hello Rogelio,

It is great we have fixed the issue after applying the parameter.

Jorge