07-12-2012 03:30 PM
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
Solved! Go to Solution.
07-13-2012 12:59 AM
Hi Rogelio
Yes, it should work like this , if cookie isn't found - L3/4 loadbalancing is done without creating or checking sticky entries.
07-14-2012 10:25 PM
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
07-16-2012 04:58 PM
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
07-16-2012 11:24 PM
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.
07-13-2012 12:59 AM
Hi Rogelio
Yes, it should work like this , if cookie isn't found - L3/4 loadbalancing is done without creating or checking sticky entries.
07-14-2012 10:25 PM
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
07-16-2012 12:24 PM
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
07-16-2012 12:40 PM
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?
07-16-2012 12:27 PM
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
07-16-2012 04:58 PM
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
07-17-2012 02:53 PM
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
07-16-2012 11:24 PM
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.
07-17-2012 02:51 PM
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
07-19-2012 06:38 AM
Hello Rogelio,
It is great we have fixed the issue after applying the parameter.
Jorge
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide