Forum Discussion
hooleylist
Jul 21, 2010Cirrostratus
Hi John,
Welcome to the forums. That's a very well thought out and described scenario.
Matt makes a good point. The other app servers would need to have access to the session details in order for this to work with minimal to no impact on the client experience.
As far as transferring the TCP connection to another server, you should be able to use the reselect option for the "action on service down" pool setting and possibly a custom "always fail" or reverse monitor to handle this:
SOL10640: Pool member reselection options
https://support.f5.com/kb/en-us/solutions/public/10000/600/sol10640.html
You can check this post for helpful info from Chris and Michael on action on service down:
Action on service down question
http://devcentral.f5.com/tabid/1082223/asg/44/showtab/groupforums/aff/32/afv/topic/aft/1172557/Default.aspx
Or instead of adding a monitor to the pool member that will always fail when you want to take a specific pool member down, you could have a page which is monitored by LTM on the application changed before maintenance begins so that the monitor check fails. The "action on service down" should then be triggered which could be to reselect a new pool member.
On a slight tangent: the JSESSIONID persistence iRule should always be deployed with a OneConnect profile to ensure each HTTP request is persisted to the correct pool member. If you're not using SNAT on the virtual server, you can set the OneConnect source mask to a host: 255.255.255.255.
Aaron