Forum Discussion
NimbostratusWhat happens to active VIP/node connections if the underlying pool is changed?
I have an environment where new software is pushed to an "offline" pool of nodes, call it POOL_A, and when ready the updated pool is swapped in hot as the active pool, replacing the former "live" pool, call it POOL_B. Persistence is set to source address. When the active pool is swapped hot, and POOL_A becomes active, do existing sessions going to members of POOL_B terminate, or do they refresh to nodes on POOL_A, assuming the application backend is handling session state and not the nodes?
I'm more accustomed to environments where active connections are drained off before removing nodes from the active pool, and wasn't sure of expected behavior with a "hot" swap.
2 Replies
- Kevin_Stewart
Employee
Your persistence method is going to create a table entry on the F5 that maps a client source address to a node IP (and port). If you just remove that node traffic flow will simply fail. If, however, you have a good monitor applied (that can reliably detect the absence of a node) and Reselect set in the pool's "Action on service down" option, a persisted connection to a failed node should be re-loadbalanced to a new node.
- Kevin_Stewart
A few things:
Persistence is an often misunderstood thing. Of course load balancing persistence means sending all traffic from a single client to the same server for the life of an application session, but there's more to it than that. There's actually two types of persistence. I'll call them TCP (or layer 4) persistence and then everything else. When the client and proxy and proxy and server initiate a pair of TCP connections, after the load balancing decision, persistence is locked inside this layer 4 connection. This is more or less automatic. Only after a TCP session has gone away and the client makes a new request do you get into the realm of the programmable persistence methods that you see in the BIG-IP management GUI. For example, if there's no existing TCP connection and the client's new request has a persistence cookie in it, then a new TCP connection is established (ie. persisted) to the same server. This is also why we have things like OneConnect - to be able to safely "break" that TCP connection when you're load balancing to different servers based on some client side request value. So to answer your questions, if you ave an existing TCP connection to a server, and that server is simply removed, the persistent TCP connection will win (in the absence of a monitor) and you could experience an error in the client browser. A monitor would prevent this behavior by sensing a server failure and forcing a new TCP connection elsewhere. Using no persistence at all would simply mean that all requests (that is all new TCP connections) could be load balanced willy-nilly across the pool. Without a good monitor though, new TCP connections can be sent to bad pool members. If you want an absolutely seamless way of removing servers from the pool, you can disable the pool member and allow time for existing TCP connections to close and move to other servers.
Alternatively though, as long as you have a good monitor applied you can pull servers from the pool with minimal effect on user experience.
