Proper setup for load balanced web that needs sticky sessions?

Question

I have found many q&a's on this subject, but I still haven't figured out the proper configuration for our servers. Background is this: We have two web servers behind a load balancer and must make sure that the user's don't loose their sessions.

• Web servers are IIS7/ASP.NET 4.
• We currently cannot setup a separate session state server and must therefor use sticky sessions on the LB.

As far as I understand, the following must be assured:

• Set same machinekey on both web servers.
• Use precompiled sites so that the assemblies get the same naming on both machines.
• We either must base sticky session on ip-number or cookie (the latter is prefered)

Is it necessary to have precompiled sites? (I know it is faster, but we loose some flexibility)

Since we have sticky sessions, is it correct that having the same machinekey only affects those cases when user's session time out and he/she therefore ends up on the other server (which means a post back containing view state might not be valid unless they have the same machine key?)

Answer 1

You are correct on all points - sticky sessions on LB would ensure that same web server will be hit on subsequent requests and hence correct in-proc session state would be available. However, its imperative that LB stickiness should match (or should be more) with the time-out value of ASP.NET session. For example, if LB is using cookie for stickiness then the cookie expiration time should be more than that of ASP.NET session.

Same machine-key argument is useful for cases where post backs for requests go to other servers for whatever reasons. The client side state (such as view-state and event validation, perhaps authentication ticket) gets encrypted with machine key so having same key ensures that any of the server can serve the post-back. On the side note, in all web farm scenarios, it makes 100% sense to have exact S/W environment (and possible H/W environment) on all web severs to avoid any surprises.

Pre-compilation of web sites is needed to avoid serialization conflicts - type names has to be same while serialize/deserialize. So you cannot have serialized types from dynamically generated assemblies and per-compilation avoids that. IMO, this would more likely to affect view-state storage rather than session state (because your session state is any way not shared and will not be available on second server). Lastly, if you are not using web sites and rather using web application projects then this point become more or less irrelevant because code files would be anyway complied while building projects. Only pages (markup) would be dynamically complied and having chances of serializable types in markup is almost zero (and sounds like bad idea anyway).