Forum Discussion
Pool Member Maintenance Process
In this scenario there is actually no way of re-associating existing connections to another pool member, the only way is to drain connections with the disabled state. There is a setting on the pool, called Action on Service Down that tells the BIG-IP what to do with existing connections in case a pool member becomes unavailable (either by way of a monitor marking the member as such, or setting the member in forced offline) and there is one option there called reselect but that is something that only works in a very limited number of scenarios and none of them apply here:
https://support.f5.com/kb/en-us/solutions/public/15000/000/sol15095.html?sr=49120474
So yeah, planning ahead is key in a maintenance situation, start by disabling the member way ahead of time in order for connections to drain. This is what most of my customers tend to do, unless they are in a hurry, in which case they tend to set the Action on Service Down setting to Reject and then setting the member as forced offline. Of course this is not transparent to the users, since they will have their connections reset by the BIG-IP but it's better than to have the client wait for timeouts in case the server is completely out of it.
What you noted about removing a member from the pool is expected behavior - the connection table is the supreme ruler of the BIG-IP, if a connection exists in the connection table that counts regardless of what the configuration looks like.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* 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