« Previous Next »

Thread: Session state is not working well in my web farm with IIS 6.0

Last post 03-14-2008 11:45 PM by steve schofield. 7 replies.

Average Rating Rate It (5)

RSS

Page 1 of 1 (8 items)

Sort Posts:

  • 03-06-2008, 11:20 AM

    • josecarlo
    • Not Ranked
    • Joined on 10-25-2004, 4:44 PM
    • LIMA PERU
    • Posts 5

    Session state is not working well in my web farm with IIS 6.0

    Hi, I have a web farm configuration with two servers running Windows Server 2003 and IIS 6.0, I'm using NLB. For my asp.net applications I'm using a state server so I've configured my apps to use StateServer Mode.

    The problem is that every server in the farm is creating its own set of session variables for the same session/user. I verified that each server can read/write session variables in the state server, the problem is when a request is handled by a server (server B), that is not the server that handled the previous request (server A). In this case, the server B creates a new session. The fact is that I can have two sets of session variables, and the values that I saved when my request is on server A are different of the values when my request is on server B. 

    I already set the machineKey element in machine.config to use the same keys in both servers:

     <machineKey validationKey="12ABC432...." decryptionKey="FA45EE..." decryption="3DES" ... />

    I also configured the sessionState of my application to use the state server:

    <sessionState mode="StateServer" stateConnectionString="tcpip=10.6.6.54:42424" ... />

    I also checked that the application paths and instance ids of the web sites in both servers are the same, and they also are in upper case: i.e. LM/W3SVC/1/ROOT ....

     I also verified that the session ids generated by both servers are the same.

     I don't know what else to check.

    Please, if somebody can help me with this.

    José Carlos Aramburú
  • 03-08-2008, 11:34 AM In reply to

    Re: Session state is not working well in my web farm with IIS 6.0

    Sounds like you have a correct setup.  Have you checked to make sure there isn't an extra session state setting in your web.config.  In cases like this, filemon from Sysinternals can help which files are being accessed. 

    Another thing I can think of is a previously compiled application has some old settings.  I would try clearing your ASP.NET temporary files.  Those are a couple things I can think of.

    I know when something like this should work but isn't.  I isolate a website to a single webpage on both nodes and perform testing.  This can rule out any application level variables causing the issue.  Doing a hello world can also verify your server config. 

    Steve Schofield
    Windows Server MVP - IIS
    http://weblogs.asp.net/steveschofield


    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget
  • 03-10-2008, 7:18 PM In reply to

    • josecarlo
    • Not Ranked
    • Joined on 10-25-2004, 4:44 PM
    • LIMA PERU
    • Posts 5

    Re: Session state is not working well in my web farm with IIS 6.0

    Well, the configuration file of the application only has this setting:

     <sessionState timeout="20" />

    The rest of the parameters are in machine.config. And the other suggestion doesn't help either because we developed a new application with only one page just for doing testing. In that page, we can check which server is attending the request, if the session id changed when the request jumps from one server to the other, our session variables, etc.

    José Carlos Aramburú
  • 03-12-2008, 5:27 PM In reply to

    • pgeorge
    • Not Ranked
    • Joined on 03-12-2008, 8:11 PM
    • Massachusetts
    • Posts 6

    Re: Session state is not working well in my web farm with IIS 6.0

    It sounds like NLB is your problem here because it does not have the ability to provide "sticky." Hardware load balancers like Cisco content services switch have this feature. Basically "sticky" forces all requests/response to the same server that initiated the session with the browser. Otherwise you'll have a situation whereby every new click is presented as a new request/session which any server in the farm can respond to. This is the reason why NLB is never used in an enterprise environment.

     

     

  • 03-12-2008, 5:30 PM In reply to

    • pgeorge
    • Not Ranked
    • Joined on 03-12-2008, 8:11 PM
    • Massachusetts
    • Posts 6

    Re: Session state is not working well in my web farm with IIS 6.0

    Steve, this sounds like a "sticky" issue. Does NLB provide sticky? I doubt it...

  • 03-12-2008, 8:29 PM In reply to

    Re: Session state is not working well in my web farm with IIS 6.0

    NLB provides a thing called 'affinity'.  Cisco calls it 'sticky session' I think. 

    http://technet.microsoft.com/en-us/library/bb687542.aspx

    Google 'affinity' and 'NLB' as key words, you'll find articles on the topic + configuration.

    Steve Schofield
    Windows Server MVP - IIS
    http://weblogs.asp.net/steveschofield


    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget
  • 03-13-2008, 2:24 PM In reply to

    • josecarlo
    • Not Ranked
    • Joined on 10-25-2004, 4:44 PM
    • LIMA PERU
    • Posts 5

    Re: Session state is not working well in my web farm with IIS 6.0

    For now, we are using the "Single Affinity" option in NLB which in theory, sends all the requests from a specific IP address to the same server in the cluster. With this configuration, our applications are working even with InProc session state.

    So, what is the point of using a state server in this case?

     It was supposed that you configure a state server and all of those configuration parameters because you want any server in your cluster attend any request with no problems, in other words, use your NLB with the multiple hosts option and affinity = none.

     

    José Carlos Aramburú
  • 03-14-2008, 11:45 PM In reply to

    Re: Session state is not working well in my web farm with IIS 6.0

    1) Using a state server allows your application to remain active during application pool recycles.  That is the main benefit, well the only one I can think of.

    2) The affinty option is ok and will work since requests go back to the original machine.  The one drawback is your environment isn't true load-balancing.  I would suggest using no affinity and try using a state server. 

    Of course, this would take testing and such, but would provide better load-balancing (more balanced) and hopefully better application stability since people's session would survive recycles.  Using a state server, the state server option is a single point of a failure.  There are 3rd products ScaleOut, NCache or MS SQL Clustering with SQL session state that provide redundancy and failover.

    Steve Schofield
    Windows Server MVP - IIS
    http://weblogs.asp.net/steveschofield


    http://www.IISLogs.com
    Log archival solution
    Install, Configure, Forget
Page 1 of 1 (8 items)
Microsoft Communities