PERSIST at the pool level only

Hi Jason,

 

What you are asking is doable, but do you have an idea of how you can differentiate your users? For example are the different users based on a parameter or cookie or source IP address they are requesting?

 

 

Bhattman

Once you figure out how to differentiate between the two sets of users, you can insert a session cookie in responses to track when a user has been assigned to one pool or another. On requests you can look for that cookie value to get them back to the same pool. You wouldn't need to use the persist command for this.

 

 

Aaron

I created an iRule for selecting the proper pool based on who's making the request, but now I have a question....we use a VIP for multiple products, each running in their own IIS app pool. One of them uses a long-running HTTP request for doing a publish/subscription type transaction where we push an update out the connection...which is using the PERSIST function to stay on a single server in the pool (the PERSIST iRule is watching for "/streamer" requests only).

 

 

How can I have both of these running at the same time?

 

 

What is the order of events with the PERSIST setting/profile and the rest of the iRules?

I don't think I understand all the pieces to answer your question - but you might want to look at the discussion at the bottom of http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/130/iRules-101--05--Selecting-Pools-Pool-Members-and-Nodes.aspx for some guidance.

If your iRule is specifically looking for requests only bound to a particular URI, and the requests using the standard persistence aren't bound for that URI, then there shouldn't be any crossover, should there?

 

 

Or would one client possibly be making requests to both?

 

 

Colin

I will actually need to hybrid the two together, but keep them separate. I'm sure that makes a lot of sense.

 

 

I have 2 complete environments behind one VIP. One client is paying for separate hardware (one set of servers) and then there's everyone else (other set of servers).

 

I need to accomplish 2 things.

 

1) I need to determine if I have client A or not client A and choose a web pool based on A or not. I'm setting a session cookie to track this and direct appropriatly.

 

2) I need to take all /streamer calls and persist to a node, but only after I pick client A or not A. So I need to only get to the correct side/pool (based on the solution for 1) then let the PERSIST kick in to the node.

 

 

If I check the URI for <> "/streamer' for the regular iRule for 1 above.... and then for 2 only process when URI = "/streamer" I should be ok?

 

 

I hope I explained that clear enough.

That should be very doable. All you need is to identify how to single out the requests for client A vs. your normal requests, and how you want to do persistence, then mush those two together. ;)

 

 

So the logic sounds like:

 

 

If the inbound request is for client A, then pool A.

 

 

Else, if the request is inbound for /streamer, then persist to a particular node

 

 

Is that correct?

 

 

Colin

Yeah,

 

if not /streamer client A then pool A else pool B (then set a session cookie to route faster for subsiquent requests)

 

if /streamer and client A, then pool A2 + PERSIST else pool B2 + PERSIST

 

 

I'm shooting for 4 pools, A1/A2 and B1/B2...the 1's would be Observed method (best that I found for regular web requests) and the 2's would be least connections since all of the /streamer connections are long running and I just want to balance based on connection count and not performance like Observed offers.

 

 

make sense? sound like a clean solution?

 

 

How would I abandon/exit the iRule as a whole?

 

 

In the iRule I have CLIENT_ACCEPTED, HTTP_REQUEST, HTTP_REQUEST_DATA, HTTP_RESPONSE, and LB_SELECTED. Would I have to check the URI in each event in order to skip the activities in each event within the same iRule?

 

 

And, the PERSIST profile has the other iRule that is assigned to a Universal PERSIST profile which is set on the VIP...and then the other non-PERSIST iRule is just in the list of iRules....is this the best way to do this?

So the /streamer portion is easy to identify. How do you identify client A vs. not client A?

 

 

Colin