Meaning of Session Persistence

Hi Frank,

 

 

What protocol is your traffic? When you say session, do you mean an application session, a TCP connection or something else?

 

 

By default, LTM does connection based load balancing with serverside connections generally matching what the clientside has. This can be altered with various profiles, including OneConnect.

 

 

Aaron

Thanks for the quick response Aaron.

 

 

The traffic is encrypted (SSL) RMI connections from tier 1 servers to middle tier RMI (EJB) servers.

 

 

The tier one servers set up a connection pool to the RMI servers when they start up and then route their client requests over these existing connections.

 

These connections can last for days or evern weeks.

 

 

The OneConnect feature sounds interesting, but I didn't find information on its behavior as the pool membership changes.

 

Two scenarios which I need to understand are:

 

 

1) How do we take down one of the RMI servers in the pool for servicing? With the basic F5 pool management we have long-lived client (tier 1) connections to servers in the pool. When I use the F5 to deactivate a server, traffic continues to flow because it maintaines existing session traffic. Not good. I would like to have traffic flow as transparently as possible to a different server in the pool so that we can service the deactivated one (all our EJB requests are stateless so each request can go to any server).

 

 

2) When we add a new server to the pool to handle increased load we need to have traffic spread across all the servers in the pool. With the existing F5 behavior and our long-lived client connections there are no new connections to blance and so the new server takes no traffic. Not good.

 

 

Is there any documentation on how OneConnect handles thiese siturations?

 

Do you have any ohter recommendations on how to handle this?

 

 

-- Frank

Hi Frank,

 

 

Thanks for the additional info. If the traffic is encrypted through the LTM virtual server, there isn't much LTM can do to break up the application "requests" and send them to different pool members. ie, OneConnect or other attempts at breaking up the connections wouldn't really help as LTM cannot inspect the application traffic.

 

 

If you can use SSL session ID persistence you would have persistence throughout the SSL session and avoid pinning one client to one pool member forever. A new load balancing decision would be made each time LTM sees an SSL session ID which is not already mapped to a pool member. This wouldn't make a big difference though if the clients aren't opening new connections.

 

 

To move connections off of a pool member you want to do maintenance on, you could set the pool's action on service down to reset or reselect. You'd then want to make the monitor fail to trigger the action on service down action.

 

 

Aaron