If you’ve attended any of my presentations in the past, especially those covering high availability (HA) you might have noticed me biting my tongue. HA in SharePoint 2007 was a specialty of mine and while I made every attempt to simplify the options,  I always got the impression that folks were more confused leaving my session than when they started. Some of that can be attributed to bad presentation skills, but I think the bigger problem is that HA options in 2007 were simply lacking and workarounds I described were complicated and full of holes. Enter SharePoint 2010.

What really sucked when talking about SharePoint 2007 was not being able to talk about the improvements coming in 2010. Now that the SharePoint Conference is over and the NDA around the 2010 server products has been lifted, I am troubled no more.

So what’s been improved in SharePoint 2010 around HA?

Database Mirroring Support

The improvement I’m most excited about is native support for SQL Database Mirroring. I can hear you now. “But Mike. You’ve been talking about SharePoint support for database mirroring for 3 years”. You’re right. I have, but the “support” I talked about was complicated workarounds. The first support option was the STSADM RenameServer command. This command would allow you to change the name of the SQL server when databases failed over to your mirror instance. Unfortunately, if you were using more than WSS, this command was useless as several SSP functions would break. The second option was SQL aliasing which at its core was simply a way to trick SharePoint to think he or she (is sharepoint a he or she? ;-) was talking to the original SQL instance when in fact SQL instance had changed. SQL aliasing has its share of problems:

• The SQL alias is created and managed on each SharePoint server. Updating requires logging into each server and changing it.
• The SQL alias works at the per instance level, but database mirroring is a per DB setting. This means that you could end up in a very bad state I used to call a “split”. A split is when some databases are principle on instance 1 and others are principal on instance 2. SharePoint, obviously confused by this, would not be able to connect to databases on one of the instances. Doh!

SharePoint 2010 to the rescue. SharePoint 2010 now supports database mirroring the proper way. The way the SQL product group intended. SQL provides a method for addressing failovers between partner SQL instances via the connection string. You can learn more about this at http://technet.microsoft.com/en-us/library/cc917713.aspx. For each database SharePoint talks to, you can define a failover partner. A failover partner is simply the other SQL server instance SharePoint might expect to find that particular database. If you are mirroring the configuration database between SQLServer1 and SQLServer2 and SQLServer1 is currently the principal server then SQLServer2 will be the failover partner. When SharePoint is unable to talk to the original SQL instance SQLServer1, it will automatically retry the connection on the failover partner, SQLServer2 after a specified timeout. Default of 15 seconds. Since each failover partner is defined at the connection string level, you no longer have to worry about Splits and since the connection will automatically be retried after 15 seconds and you don’t have to worry about changing anything manually. Win Win!

Index Server Redundancy 

Yay! I no longer have to talk about single points of failures inherit in the product! Having to tell people to rebuild search if the index server was lost or corrupted was a thorn in my side. In SharePoint 2010, search employs a better search topology including redundant crawlers. This is one of the many fallouts from the architectural improvements around the Shared Server Provider, now called Shared Service Applications. More on that later. See the below diagram for an example of how a redundant search infrastructure might look.

Throttling

Now most people wouldn’t consider throttling a feature of high availability, but if you ever used an overburdened server, you might hear me out. Throttling is a new capability in 2010 that essentially checks resource usage on the local server and when monitored KPI’s exceed administrator defined thresholds SharePoint will issue out 503 errors to new users until the server state improves. This ensures that existing requests will be completed before new requests are accepted. Throttling is configured on a per web app basis and by default will monitor CPU and memory utilization, Request Wait Time, and Requests in Queue.

Upgrade and Patching

SharePoint 2010 provides a more cohesive story for availability during upgrades and patching. First, there is better support for read-only databases which allows users to access content while you upgrade or patch that content in another location. With a carefully scripted process, users might not notice anything ever happened. Additionally, SharePoint supports simultaneous database attach via Powershell which may reduce downtime associated with patching by multithreading the upgrade process. (mileage may vary) There is also an option to redirect users to a 2007 farm on a per AAM basis which could reduce perceived downtime on large farms with multiple web applications since the entire farm doesn’t have to “appear” to be undergoing upgrade. Finally, there is an option during patching to schedule the disruptive portion of the patch (the database upgrade part) so that downtime can be scheduled for a better time.

All in all, there are many solid improvements in SharePoint 2010 that should lead to more uptime. I’m confident that shops large and small will welcome these new features with open arms. Tune in next time for my blog on content recovery improvements in SharePoint 2010.