Forum Discussion

Chris_Olson's avatar
Icon for Nimbostratus rankNimbostratus
Jan 06, 2011

Saving sessions during server failure

We have an applilcation running on .net and our dev group is working on trying to write session persistance. I KNOW the F5 can do this, but need to get them started. I am not a developer but have worked with some basic irules, etc. Currently, when users are logged on to a server and that server goes down or is removed from the pool due to a health monitor, they lose their session. They have to close their browsers, then log in again and start over. Currently our application runs using the In-Proc configuration where sessions are kept as live objects in web server (aspnet_wp.exe) thus, when the webserver crashes all the sessions are also gone and users can’t continue with what they're doing. Ideally, we want to be able to cache their sessions so when they are bounced to another server in the pool, they can resume where they left off. What is the best way to do that? The standard cookie or source persistance profiles don't save their work in the application. Can F5 do this or does it need to be written into the application? Action on "Service down" is set to "Reselect."Any suggestions are appreciated. Thanks, Chris


8 Replies

  • Hi Chris,



    If the client's session data doesn't exist on or isn't accessible from the other application servers, re-load balancing the connections/requests isn't going to do anything to make their application session work. You would need to have some kind of session state mirroring done within the application stack. That could be a significant structural change.



    If you want LTM to reselect a new pool member when the current pool member is marked down by a monitor, you could do this using the action on service down pool setting that you pointed out.



  • I thought perhaps we'd be able to mirror/cache the sessions somewhere on the F5 but it looks like their proposal to add a separate server to hold all the state session objects is the way to go. Thanks for setting me straight.


  • Hey Chris,


    We normally have our clients use an MSSQL DB for session state.I believe there is some kind of script in the ASP.NET folder which can create the DB and the necessary tables. Then, you can go into the IIS website properties and specify the connection string in the Session State properties.
  • Thanks for your input. I really am interested in how they plan to do this. I assume you are still using the F5 to load-balance the inistial connection. Is that correct? There is a grey area here on how the F5 and the session state load-balancing occurs without stepping on each other. Any generic documentation or links on how this occurs would be appreciated.


    Thanks again,


  • Hi Aaron,


    When you say "significant structural change" does this mean we would no longer use the F5 if they go down the road with session state balancing? Can the app and the F5 still coexist without stepping on each other?






  • The significant changes I was referring to was how to sync the application session data between the application servers. If the application owners are able to share the application session information across different application instances (possibly using MSSQL as rjordan suggests), you probably wouldn't need to use persistence on LTM. You definitely could, but it shouldn't matter which app server gets the request if all of the pool members know about the client's session.



  • Lori MacVittie wrote a great article about Session State with the message being that the DB is a great place for this.





    We do it at the App Level with WebLogic and it's such a resource consumer, we have to turn it off during peak levels.



    My favorite thing about session replication is that it allows you to load balance HTTP Requests rather than just TCP Connections. Using OneConnect with no persistence, I'm able to take a user who sends 12 HTTP Requests and send 3 to each of my 4 servers. It makes for some very efficient resource usage.
  • Thanks Chris. Good infromation and a good article which makes it easy to understand. We will be testing the OneConnect profile.