Forum Discussion
NimbostratusSticky Sessions based on application key/logic
Hello,
I just wanted to check the feasibility of implementing the below scenario using iRules/any other options provided by the tool.
The usual way of implementing sticky sessions is through cookie persistence where a client once associated with a node is automatically redirected to the same node based on the cookie that's set on the first request. Our requirement is to have sticky sessions but the stickiness is required at a level that's based on application key/logic. As an example, let's say, an application works with 'n' objects. Although an initial request for an object can be handled by any of the servers, if a request for say object 'x' hits a server m, all future requests for object 'x' by any user (or from any machine) should hit server 'm' only. So, in this sense, the stickiness is to the object (or object ID) rather than client machine/browser. As application developers, we can embed the object ID or any other identification in the HTTP headers/request and even though I can extract the object Id from the request data via iRules, as long as I don't have the ability to store earlier mapping data/table I won't be able to solve this affinity problem. At least, I think so.
Do we have a way to solve this problem? Please let me know.
Thanks in advance.
-Chaitanya
2 Replies
HamishCirrocumulus
Yeah. You can do it. You can either store the mapping in a cookie that you set from the iRule and grab again next request (Which means you only have to parse out the object once, but you really do have to encrypt the cookie to stop tampering) or use a table.
The cookie has the advantage of better scalability (To infinity because it's not your storage you're using). Tables work with clients that can't set arbitrary cookies...
H
giltjrTo make sure I understand:
You have "Pool1" with "Server1" and Server2"
User1 makes a request with object "X" and the F5 sends to "Server1". You now want to send all requests with object "X" to "Server1" no matter what user it is?
At what point in time would you send a request for object "X" to a different server? Or would every request for object "X" always (as in "forever") go to the same server.
