Forum Discussion

jpimmel_46830's avatar
Icon for Nimbostratus rankNimbostratus
Nov 16, 2010

First time trying to write iRule: neend to dertermine how to switch affinity users from INACTIVE pool member to ACTIVE pool member

Hi All



Its been a long time since I wrote any iRules and I am struggling to get a solution that would work for the following problem.



Our write-heavy web app uses non-clustered user sessions, for better or worse - it was from before my time, and to provide a good user experience F5 ensures session affinity to the server to which you were first directed. That all works great. The problem we have is at deploy time; we currently need to remove servers from the ACTIVE pool and wait for several hours until all the users who still had sessions on a given INACTIVE server have slowly filtered off. Clearly this isn't ideal.



Since it's less intrusive for us to write a rule than to fundamentally change how we manage user state in the app, we identified a way we thought we could accelerate the filtering off process.



Its important to point out that we can easily push users from one server to the other and re-initialise their user state on the new server because we use CAS/Single Sign On. The token they have when they float between servers restores their user session seamlessly; however if we bounce a user off a server when they are submitting an update of data, then we risk losing that specific update.



Within the app the main entry point is just a list of inventory. This apge is unqiue because requests to that URL never submit anything. The idea was that we could add a rule which fond users accessing those URLs and if they were currently on an INACTIVE node we could bump them off to an ACTIVE node.



Here's what we have so far. We reasoned that we could somehow flush out the old cookie that bound them to the INACTIVE node and therefore trigger them to be reassigned to anothre (therefore ACTIVE) node.



if { ([HTTP::uri] starts_with "/products/car/list") or ([HTTP::uri] starts_with "/products/engine/list") or ([HTTP::uri] starts_with "/products/boat/list") } {


if { (![HTTP::cookie exists "push_08_03"]) } {


set remove_persist_cookie 1


persist cookie rewrite BIGipServerSessionCookie_http_pool -1


HTTP::cookie remove "BIGipServerSessionCookie_http_pool"


HTTP::cookie insert name "push_08_03" value "1"


log local0. "products_http_set rule: [IP::client_addr] - [HTTP::host][HTTP::uri]"







However, while elements of this works it requires they hit that URL twice.. Which in reality they wont do a great deal and which will significantly reduce the rate at which we can catch users and move them.



We're wondering if we approaching this correctly? Is messing around with cookies the way people would tackle this, or are there other ways which are better suited to solving this?



On the surface it seems like something BIGIP could do, but do others agree?



2 Replies

  • i'm a little bit confused. why do we have to manually manage persistent cookie when pool member is down? ltm should do it for us. am i wrong??



    this is article i found.



    LTM: Action on Service Down




    SOL10640: Pool member reselection options

  • I was unaware of the LB:reselect command.. thats precisely why I posted since I had a sense that I might be going about it the wrong way