Long Persistent Sessions and no outage deployments

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