Forum Discussion
Joel_45259
Nimbostratus
Oct 03, 2007How 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
- hoolio
Cirrostratus
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 - Joel_45259
Nimbostratus
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 - hoolio
Cirrostratus
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 - Joel_45259
Nimbostratus
uRule!
Thank you very much! OneConnect profile was the answer and now LB_SELECTED event occurs on every request.
We salute you!
Joel - hoolio
Cirrostratus
Glad to hear it worked.
Aaron
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects
