Forum Discussion

Frank_29877's avatar
Icon for Nimbostratus rankNimbostratus
Feb 14, 2011

Meaning of Session Persistence

The doc on configuring persistence says "The primary reason for tracking and storing session data is to ensure that client requests are directed to the same pool member throughout the life of a session or during subsequent sessions."



Does this mean that if I disable all persistence, then even requests within one session will be load balanced?



Every request to our application is stateless and has no affinity to any server, so we would like to load balance ALL requests. This is especially important for long-lived connections.



-- Frank

3 Replies

  • 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.



  • 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.