First up, I want to talk about AlwaysOn High Availability (HA). In short, this feature combines the best of clustering and mirroring to make your applications highly available.
So why is this new feature so cool?
- Shared storage, such as a Storage Area Network (SAN), is not required.
- This feature groups databases together instead of having to interact with each database as you would with mirroring. Up to four replicas of your data can be in the same data center or in another country.
- The administrator has the ability to define policies and fine tune when to failover and how.
- One of the very best parts of this new feature is a single connection name for your applications. This means third party apps no longer have to natively support your HA solution as with mirroring!
- Lastly, to improve performance, backups can be performed on a secondary replica instead of bogging down the primary.
Most of my involvement with SQL Server has been as a SharePoint administrator. Anyone who has been a SharePoint admin knows we are all, in some capacity, a SQL admin too. So for this reason I will highlight how these features can specifically benefit SharePoint.
I have deployed both clustering and mirroring to provide High Availability for SharePoint in the past. Both of these methods have strengths and weaknesses. For clustering it’s the complexity of shared storage. For mirroring its that all applications have to natively support it.
As mentioned with AlwaysOn, you get clustering without the need for shared storage. From this comes a huge plus to the third-party apps so many SharePoint deployments run: a single connection point. Third-party apps do not need to natively support AlwaysOn to work with your HA deployment. No more explaining to customers that their 50K add-on won’t be available at their DR site!
Another great feature that benefits SharePoint are the improvements to automatic failover detection. With the older versions of mirroring and clustering, failovers could happen for no apparent reason. (And finding the reason for the failover can be challenging.) With flexible failover policies you now have the power to tune when to fail and what to do during a failure.
AlwaysOn can be deployed immediately after your upgrade/deployment, or at a later date. AlwaysOn can be deployed no matter what upgrade method is chosen. SQL Server 2012 still supports standard mirroring but with so many improvements, why not switch to AlwaysOn?
How does this new feature solve problems in your organization? Feel free to comment!