SharePoint Sticky Sessions and Persistence
Does SharePoint Require Persistence?
Try to find the answer to that in the docs. It doesn’t say.
Because it depends…
With WSS if you’re using NTLM you might never notice if you didn’t setup persistent connections. With plastic SharePoint you could use it as a document sharing platform and never require persistence.
If you’re using Basic over SSL you definitely will. You’ll get prompted twice.
If you’re using forms and cookies, again, you’re going to have issues.
If you’re using client certificates, again, issues.
Kerberos? don’t even think about it.
So is it just authentication that forces this? No, if you have forms that require session state then you should have a persistent session. Multi page forms and .NET apps that require session state will fail if they user gets sent over. Some session state apps are setup to keep the persistence despite the server, but I don’t think we need to go there.
Do I recommend persistent or sticky sessions with load balancing of software or hardware?
YES! By default setup persistent sessions/connections. You want people to stick with one server, and what happens when that server goes down is up to the load balancer.
Would I ever recommend not to have persistence?
Rarely. For pure load balancing performance statistics it’s nice to have a the session easily move across the servers. Load balancing people in a stateless world often prefer no persistence, but application people prefer the persistence.
What about Round Robin DNS?
What year is this? Yeah, in some cases round robin can provide interesting solutions around sets of NLB’ed servers or even between pairs of hardware load balancing devices. The complexity goes up for sure. Pure RRDNS, I don’t recommend, I’d say go with NLB before pure round robin. You will get some persistence out of the client DNS cache, but you still may get intermittent issues that are tough to track down and troubleshoot.
What do I get out of persistence and sticky sessions?
- Your logs are much easier to follow and troubleshoot.
- Your can avoid the double prompt
- End user issues are much easier to identify
- Forms and sessions will continue to persist and be more reliable.
- I think there’s even an argument that you’ll end up using less memory, but I won’t dig into that here.
- The Index server or external crawlers out there won’t smash both boxes (just one) 🙂
So with all that if you go and ask a company what they’re using you’d find that most people do setup persistence, but would be tough to quantify why.
SharePoint tries to stay agnostic to load balancing software and hardware, so let’s not make the SharePoint team give us a thumbs up or down. We’re smart enough to figure this one out. Let the load balancer manage the session state and the stickiness. And as always, I recommend some good testing before throwing it out into production.
Does SharePoint Require Windows Load Balancing or NLB? No.
Does SharePoint work with Hardware Load balancers? Yes.
Do you recommend NLB or Hardware load balancer?
What’s the SLA? If it’s over 99.9% I’d seriously lean toward hardware. I think latest ISA and IAG shouldn’t be overlooked for intelligent solutions as well. NLB is smarter than round robin DNS, but still needs more brains (like understanding HTTP/S a bit better)… too little too late.
Is Cisco or F5 better? Whoa… I think there are some great solutions out there.