Disclaimer: I am not a database expert, nor have I had the chance to
personally use SQL Server 2012
High availability has always been a bit of a pain for SharePoint. It sounds easy enough. For the presentation layer just add more Web Front End Servers. For the Application layer just add more application servers and run the Service Applications on multiple servers. But what about the database?
In the past the main options here were either clustering, mirroring or log shipping. Each one of these options was good at something's, but they all had their share of limitations. For instance clustering was great on the server side, but all the servers in the cluster shared the same storage; mirroring provided separate storage, but you could only have one mirror; log shipping provided multiple replicas and separate storage, but is a very manual process. Then to top it off both log shipping and mirroring do not allow any access to the mirror or replica databases. As you can see none of these options make for a great solution.
Recently Microsoft released SQL Server 2012. As you expect this contains some great new features. Here is a link to a MSDN blog with the top 10 new features for SharePoint:
http://blogs.msdn.com/b/nikosan/archive/2011/10/26/top-10-sql-2012-denali-enhancements-for-sharepoint.aspx
As you can see there are some neat things SharePoint can now take advantage of. The one I want to focus on is Always On.
Always On now promises to provide us with a true High Availability option for the data tier. It appears that Always On has combined the best of Clustering with the best of Mirroring. Always On allows you to setup a single DNS entry into a cluster of multiple SQL Servers, but it allows for each SQL Server node to have its own storage. It also has another nifty feature of being able to create Availability Groups. Availability Groups allow you to logically group databases that fail over together. Allowing you set different levels of high availability for different SharePoint farms within the same Always On cluster. This is huge from a licensing point of view as it allows you even more flexibility within shared SQL Servers, while still being able to provide the level of redundancy required by the business. Finally as an added bonus the fail over nodes are left in a read only mode. This allows us to report off the fail over nodes rather than going against live node when required.
What I'm still uncertain about is how this all works with the Service Application databases within SharePoint 2010. Many of the SharePoint 2010 Service Application database do not support either Log Shipping or Mirroring <Shameless Plug>To find out which Service Application databases are supported by either Log Shipping or Mirroring, see the SharePoint Reference Architecture document </Shameless Plug>. My hunch is that since they put a lot of time in making this feel like a clustering solution (that doesn't require shared storage) is that all the Service Application databases would all be supported within Always On. But as always we will need someone to test it first before we can know for sure.
In any event, if you are designing a High Availability solution consider using SQL Server 2012 and let us all know how it goes.
High availability has always been a bit of a pain for SharePoint. It sounds easy enough. For the presentation layer just add more Web Front End Servers. For the Application layer just add more application servers and run the Service Applications on multiple servers. But what about the database?
In the past the main options here were either clustering, mirroring or log shipping. Each one of these options was good at something's, but they all had their share of limitations. For instance clustering was great on the server side, but all the servers in the cluster shared the same storage; mirroring provided separate storage, but you could only have one mirror; log shipping provided multiple replicas and separate storage, but is a very manual process. Then to top it off both log shipping and mirroring do not allow any access to the mirror or replica databases. As you can see none of these options make for a great solution.
Recently Microsoft released SQL Server 2012. As you expect this contains some great new features. Here is a link to a MSDN blog with the top 10 new features for SharePoint:
http://blogs.msdn.com/b/nikosan/archive/2011/10/26/top-10-sql-2012-denali-enhancements-for-sharepoint.aspx
As you can see there are some neat things SharePoint can now take advantage of. The one I want to focus on is Always On.
Always On now promises to provide us with a true High Availability option for the data tier. It appears that Always On has combined the best of Clustering with the best of Mirroring. Always On allows you to setup a single DNS entry into a cluster of multiple SQL Servers, but it allows for each SQL Server node to have its own storage. It also has another nifty feature of being able to create Availability Groups. Availability Groups allow you to logically group databases that fail over together. Allowing you set different levels of high availability for different SharePoint farms within the same Always On cluster. This is huge from a licensing point of view as it allows you even more flexibility within shared SQL Servers, while still being able to provide the level of redundancy required by the business. Finally as an added bonus the fail over nodes are left in a read only mode. This allows us to report off the fail over nodes rather than going against live node when required.
What I'm still uncertain about is how this all works with the Service Application databases within SharePoint 2010. Many of the SharePoint 2010 Service Application database do not support either Log Shipping or Mirroring <Shameless Plug>To find out which Service Application databases are supported by either Log Shipping or Mirroring, see the SharePoint Reference Architecture document </Shameless Plug>. My hunch is that since they put a lot of time in making this feel like a clustering solution (that doesn't require shared storage) is that all the Service Application databases would all be supported within Always On. But as always we will need someone to test it first before we can know for sure.
In any event, if you are designing a High Availability solution consider using SQL Server 2012 and let us all know how it goes.
Every writer wanted to have their writing into the top side and stay happy. In this site http://www.articlerewriteservice.net/ there you get paragraph writing services like people wanted there.
ReplyDelete