Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

we have a web farm of IIS7 machines. Works great. In front of them is an F5 Big-IP hardware load balancer. Also working fine :)

alt text

Now, currently we're using an ASP.NET State Service to handle our OutProc state. This is required when you have a web farm to maintain any type of session information.

I was wondering if we could have sticky sessions on the F5 Big-IP and therefore change from OutProc back to InProc? If so, what's the downside of this? I know the downside of InProc vs OutProc, so don't worry about explaining that. I'm more interested in the pro's/con's of sticky sessions with out F5 Big-IP.

Can anyone shed some light and/or experience?

share|improve this question
add comment

3 Answers

up vote 9 down vote accepted

There are two main downsides:

  1. Your load isn't evenly distributed. Sticky sessions will stick, hence the name. While initial requests will be distributed evenly, you might end up with a significant number of users spending more time than others. If all of these are initially set to a single server, that server will have much more load. Typically, this isn't really going to have a huge impact, and can be mitigated by having more servers in your cluster.

  2. Proxies conglomerate users into single IP's, all of which would get sent to a single server. While that typically does no harm, again other than increasing individual server loads, proxies can also operate in a cluster. A request into your F5 from such a system would not necessarily be sent back to the same server if the request comes out of a different proxy server in their proxy cluster.

AOL was at one point using proxy clusters, and really screwed with load balancers and sticky sessions. Most load balancers will now offer sticky sessions based off of C-Class net ranges, or with the case of F5, cookie based sticky sessions which store the end node in a web request cookie.

While cookie based sessions should works, I've had some problems with them, and typically choose IP based sessions. BIG HOWEVER: I'm mostly working on internal apps - DMZ milage might vary.

All that being stated, we've had some great success with sites running behing F5 with sticky sessions and In-Proc sessions.

You also might want to take a look at one of the in memory distributed caching systems like Memcached or Velocity for an alternative to session being stored in SQL or the out of proc memory service. You get close to the speed of in-proc memory with the ability to run it across several servers.

share|improve this answer
    
Besides CPU, are there ways to check the current connections and/or bandwidth natively on a windows 2008 machine with IIS7 ... to see if a server is getting too hit/busy? Basically, what metrics do you use to make sure servers aren't getting blasted? –  Pure.Krome Jul 27 '09 at 7:27
    
We used a mix of sticky IP and sticky cookie sessions quite a while back and found uneven distribution, but not horribly so. The AOL proxy cluster was a nightmare for IP clustering and we had to hardcode exceptions. –  ericslaw Jul 27 '09 at 14:25
    
Native Perf Counters will show active HTTP connections. –  Christopher_G_Lewis Jul 27 '09 at 15:36
    
@Christopher_G_Lewis Would you mind to elaborate a bit on the problems you had with cookie based sessions on F5? –  Eugene Beresovksy Aug 16 '12 at 0:50
add comment

I recently read a great article in TechNet regarding "Providing Scalability for ASP.NET Applications". It went into the pros and cons of each possible solution. Take a read:

TechNet June 2009 - Providing Scalability for ASP.NET Applications

share|improve this answer
add comment

In addition to the excellent answer from Christopher, sticky sessions mean that you've lost a couple of the huge benefits of redundant servers -- the ability to take one or more down for maintenance, and transparency in the face of system failure.

I consider sticky sessions a strong indicator of poor application architecture and/or poor programming. "Avoid at all costs" is my motto.

share|improve this answer
    
Excellent thoughts on the maintenance. We throw a DRAIN on a server long before taking it out of the cluster. DRAIN means current sessions are processed, but no new sessions started on that server. –  Christopher_G_Lewis Jul 27 '09 at 15:35
    
Thankfully nobody ever has to do a maintenance at short notice, nor does a server ever unexpectedly die (causing all of the sessions stuck to that server to be suddenly useless -- I bet customers love that). –  womble Jul 27 '09 at 22:47
    
Can u DRAIN from a server without having to do any config on the F5 itself? Basically, we don't have access to the F5 (it's managed for us, in a managed hosting scenario) .. but we have full access to our web servers .. so can u DRAIN by dropping a file or something in a website? –  Pure.Krome Jul 28 '09 at 1:48
    
Our F5's determine server up/server down/drain via a text file in the web site - context of the file is "UP/DOWN/DRAIN". Examine your IIS logs to determine what they are looking at. Note that sometimes the F5 is just doing a SYN/ACK on a TCP/IP port, in which case you'll have to have your hoster change the F5's config. –  Christopher_G_Lewis Jul 29 '09 at 2:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.