Forum Discussion

Mike_S_59924's avatar
Mike_S_59924
Icon for Nimbostratus rankNimbostratus
Feb 23, 2011

irule to do smarter cookie persistance

I have a very interesting dilemma. We inherited through acquisition an application w/ some very strict persistence requirements. Not only must a user stick to the same load balanced web server but that web server must communicate via web services to the same application server through the length of the session. The number of web and applications servers varies throughout the year as they add more during busy periods. They accomplished this before the acquisition with a Cisco CSS load balancer. Essentially I need to make this work w/ no application changes or there will be pressure to put a Cisco on our network (I'm trying very hard to avoid this).

 

 

The browser to web box was easy as a simple cookie insert persistence profile did the trick. THe Web to application part of this was not working consistently with this option. Upon investigation, it seems that the LTM is not consistently creating the cookie. As this is done via web services in code, I don't really know how to investigate plus if the investigation turns up a coding change requirement, it might be shot down. They then informed me that they had this same issue w/ Cisco and instead of figuring out why, they just created a custom cookie w/ the server name in it that they set and told the Cisco to use that for persistence.

 

 

I tried the LTM option for this of cookie hash and it didn't work. I then read about the hash and was blown away by F5's reasoning that this was a realistic way to do persistence. It seems the CRC32 value of the cookie mod (number of servers in pool) must be unique and ordered for this will work. Else no go. Sheesh. Again asking for them to make changes to the code will probably result in pressure to put the Cisco device on the network.

 

 

I read about Passive but it seems for that to work, they will have to change code for the custom cookie to return the value that maps to IP's and Ports in the same way as the LTM does. ie. code change again.

 

 

So basically 2 questions.

 

 

given a custom cookie that looks something like this: customcookie=xxservername , would any of the LTM cookie persistence options have the desired effect?

 

 

If not.

 

 

Any suggestions for an irule that would accomplish what I want? One small twist is that I would like the irule to clear the cookie and and start session over if the node went down.

 

 

Thanks in advance!!!

 

  • Hi Mike,

     

     

    I suggest troubleshooting the default cookie insert persistence as that's the simplest option and it should work.

     

     

    With default cookie insert persistence using a session cookie (no timeout), LTM will only set the cookie when a new load balancing decision is made. If the client presents a persistence cookie and the pool member is available, LTM will not set the same session cookie again as the client already has it. Does this explain the behavior you were seeing?

     

     

    You'll also need to add a OneConnect profile to ensure LTM does request based persistence instead of per-connection. If you're using SNAT of any kind on the connections to the pool members, you can use the default OneConnect profile with a source mask of /0. If you're not using SNAT, create a custom OneConnect profile with the source mask set to /32.

     

     

    Aaron
  • Thanks for the response. Unfortunately there is no appetite for a research project for an issue that was supposedly researched years ago w/ no avail and a quick fix (employing the Cisco). I really would like a simple cookie way of doing this based on a server based cookie and the LTM play in this space (the cookie Hash) is the most absurd thing I've ever seen.

     

     

    Still hoping someone can provide ideas as how to do this in an irule. I'll take anything!!!!!

     

     

  • Let me confirm the scenario. Do you have a two tiered web app with a web tier and app tier? Do both sets of requests (from client to web and web to app) need to be persisted to the same servers? If so, you could potentially use an iRule on the web to app virtual server which persists based on the client's web virtual server persistence cookie. You could use 'persist uie $web_vs_cookie_value' to do this in HTTP_REQUEST. With this or any other layer 7 per HTTP-request persistence method, you'll need a OneConnect profile for each virtual server.

     

     

    Any solution you come up with for LTM is going to require testing to confirm it will work. So I'm not sure the lack of appetite for a research project is going to be workable.

     

     

    How would a custom cookie which has the server name specified be different than the default cookie insert persistence? Yes, you could rewrite the cookie insert persistence functionality in an iRule. But why would you?

     

     

    Aaron
  • Aarrn,

     

     

    It's not that I want to rewrite the insert cookie logic but it doesn't work for how this application is written and I don't know where to go to figure out why. If I can't come up w/ a way to do it on our preferred equipment (even if it ultimately takes some testing) we will become a Cisco shop. We are under some pressure to get this working. Telling them to go back and mess w/ their code to figure out why it is not doing something the way our load balancer wants it to will not fly.

     

     

    If you could provide the syntax to this in an irule, I would really appreciate it. I appreciate your help but it is not open to debate. I either need to find a way to make this work w/o application research and code change or put another device on my network. Unfortunately the real world happens.
  • Good news. The Oneconnect profile has appeared to fix the issue subsequent to some more load testing. I take it you reccomend putting that on any Virtual Server w/ cookie persistence? For some reasons we've never had persitence issues with just plain cookie for our Internet facing Web Servers.
  • Hi Mike,

     

     

    Glad to hear that's working for you. See this wiki page for an explanation of why you need OneConnect with layer 7 per-request persistence like cookie insert persistence:

     

     

    http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/oneconnect.html

     

     

    Aaron