Forum Discussion

Mike_Young_6152's avatar
Mike_Young_6152
Icon for Nimbostratus rankNimbostratus
Nov 14, 2012

Closing Active Connections sooner for maintenance

Background on the problem:

 

I have a pool setup of 6 windows machines executing .NET web services in IIS 7.x. During a deployment process we use iControl to disable 3 servers at a time to update the web service code/configuration. The problem is it takes a very long time for active connections to those pool members to die off. I want to figure out a way to quickly and cleanly kill the connections. The pool is set to round robin.

 

I have done some searching on the forums here and have found questions similiar to mine but most involve taking all pool members out for maintenance. The solution usually involves an iRule to check active_pool_members <1 then redirect to a maintenance page.

 

A possible solution I have come up with but not tested is to add this iRule:

 

when HTTP_REQUEST{

 

switch [LB::status]{

 

"session_disabled" -

 

"down"{

 

HTTP::close

 

}

 

default{}

 

}

 

}

 

I believe it checks the status of the pool member selected for this request and if it is down or disabled it then calls the HTTP::close which is supposed to close the connection after the response is sent. https://devcentral.f5.com/wiki/irules.HTTP__close.ashx

 

This feels a bit convuluded and not the best approach. Has anyone run into this problem before or can validate I am on the right track?

 

Thanks

 

-Mike

 

 

config
design

12 Replies

Sort By
Show More
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Nov 20, 2012
    If you want to close the connections for specific server addresses, why not delete the connection table entries using 'tmsh show sys connection ss-server-addr 1.1.1.1'?

     

     

    Aaron
  • Mike_Young_6152's avatar
    Mike_Young_6152
    Icon for Nimbostratus rankNimbostratus
    Nov 20, 2012
    I don't have access to the actual F5 devices to execute the tmsh command. I only have the ability to disable nodes from an iControl application. We were also looking for a way to more evenly distribute traffic across the particular pool in question so OneConnect actually fixed two of our problems. The OneConnect in my scenario seems to be working great in my testing scenarios. Production might be a different beast with higher volume of requests.

     

     

    On another note I changed the Client and Server profile of the virtual server to tcp_optimized_wan and tcp_optimized_lan respectively and the performance was much better as well. I cannot say with 100% certainty that it was the only reason but it was recommended by this article:

     

    http://www.f5.com/pdf/deployment-guides/oneconnect-tuning-dg.pdf

     

     

    -Mike