Options

Draining for Maintenance

shannontutenshannontuten Member ✭
in System
Any suggestions on the best way to drain all connections from a server so that you can perform maintenance? In a non emergency situation I'd like to let active connections continue to a server but not to allow new connections. In time that would mean that the server would no longer have any connections and the end users would not have been disrupted in any manner.

Thanks for any tips.

Comments

  • Options
    shannontutenshannontuten Member ✭
    edited February 2014
    I had tried using the priority with no luck. After reading back over the help it seems that "Scan All Members" needs to be checked on the persistence template, perhaps? I have made sure the "Scan ALL Members" is checked on the template for my test and it does seem that connections are starting to move from the server with the lower priority.

    I'll report back if it does indeed seem to be the piece I was missing.
  • Options
    cwoodfieldcwoodfield Member ✭
    edited February 2014
    Unless there's a detail I'm missing, what you are describing is the default behavior when a server, service group, or virtual server is disabled (either administratively or via failed healthcheck). New connections are not sent to the server, but established connections continue to completion. Are you not seeing this behavior?
  • Options
    shannontutenshannontuten Member ✭
    edited February 2014
    So new connections would be sent to the other server(s). When you say "established connections continue to completion", you mean in flight conversations? I'm wanting to go a step further and let any persistence to continue to send an existing client to that server. This way it will reduce any chance of the end user noticing the server going down. An example would be two web servers that don't persist session state to a central location. The user would continue to get their session state until they would normally be idled off the server. If they reconnected it would be to the new server.

    Does that make any sense? If disabling a server works that way it would be fantastic. Otherwise it does appear that setting the priority and waiting (with the "scan all members" option selected) does seem to allow the server to drain. In my scenario I'm having to change that priority on several service groups, but if disabling the server doesn't act the same way I'm willing to take the extra steps.

    Thanks for the info. If you can't answer I'll set up a test the first chance I get and see how it goes.
  • Options
    shannontutenshannontuten Member ✭
    edited February 2014
    In my testing it seems that if you disable a server that it allows the active sessions to finish and then takes the server out of the pool thus forcing the clients to the other server -- certainly useful. I found that if I change the priority in the service group that the connections start sheding quickly and tend to train in a couple of hours (varies on idle and persistence settings).

    My thought is that if I know I need to patch a server but it isn't critical then I'll go change the priority and "come back later". This way all the clients will move to the other server(s) "naturally", if you will. I then disable the server for good measure and proceed with patching.

    If I have an event that requires immediate attention, disable the server and wait a few minutes for everything to finish up and then proceed with whatever needs immediate attention.

    If there is an event that falls in the middle of those two -- say I can't wait for the amount of time it takes to drain completely (or don't want to) then change priorities, wait as long as I can and then disable the server and proceed.

    So far this seems to keep my outage completely behind the scenes from the masses.
Sign In or Register to comment.