Forum Discussion

Joel_45259's avatar
Joel_45259
Icon for Nimbostratus rankNimbostratus
Oct 03, 2007

How to change active member in the pool without losing sessions?

Hello,

We have virtual server with 2 members in a pool where only other member at a time is active. When changing the active member, active sessions should still use the original member and the new connections go to the newly activated member. We change the active member by enabling and disabling them in the pool.

We are using the HTTP cookie insert as a persistence method and the cookie's name is LBSESSION. We have an iRule that removes the cookie at the logout:


  when RULE_INIT {
    set ::remove_lbsession 0
  }
  when HTTP_REQUEST {
    if { [HTTP::uri] equals "/jsp/ssl/logout.jsp" } {
       log "need to remove LBSESSION"
       set ::remove_lbsession 1
    }
  }
  when HTTP_RESPONSE {
    if {$::remove_lbsession==1} {
      log "Removing LBSESSION"
      HTTP::cookie remove LBSESSION
      HTTP::cookie insert name LBSESSION value "0" path "/"
      HTTP::cookie expires LBSESSION 0 absolute
      set ::remove_lbsession 0
    }
  }

The iRule works as planned and removes the cookie from the browser. Any way the big-ip do not respect that but continues to use the old member though it should select a new member, set LBSESSION cookie again and fire LB_SELECTED event at the next connection from the browser.

Does anyone have any ideas or solutions for our problem? We would appreciate some help on this.

Best regards,

Joel Mäkinen

5 Replies

  • You're using a global variable, ::remove_lbsession to track when to delete the cookie. Global variables are accessible for all requests, so this may lead to trampling of the value and unexpected results. I'd suggest first changing the rule to use a local variable. I wouldn't use the RULE_INIT event at all. You can set a local copy of the variable in the HTTP_REQUEST event using 'set remove_lbsession 0' and then update it to 1 if the request is for the logout page.

     

     

    If you're still seeing unexpected results, add logging in the HTTP_REQUEST event to see if the client is presenting the cookie after you've tried to expire it.

     

     

    Aaron
  • Thanks for your quick reply!

     

     

    We did as you suggested and now logging reveals that the cookie is destroyed from the browser. However browser is still directed to the same pool member and no LB_SELECTED event occurs. Why is that? How does BIG IP make the decision to select the pool member without persistence cookie?

     

     

    Regards Joel
  • Hi Joel,

     

     

    Are you disabling sessions on one member of the pool and then seeing requests sent to the pool member that is disabled? If the client does not present a persistence cookie and the pool member is disabled, the request should be re-load balanced.

     

     

    The only case I could see this not happening in is if the client is making multiple HTTP requests over the same TCP connection. Can you add a OneConnect profile to the virtual server and retest?

     

     

    Thanks,

     

    Aaron
  • uRule!

     

     

    Thank you very much! OneConnect profile was the answer and now LB_SELECTED event occurs on every request.

     

     

    We salute you!

     

     

    Joel