We’ve been in the process of building a team site in SharePoint 2013, and since I’m building I decided to investigate using AlwaysOn Availability Groups. This is slightly different than building a normal availability group—the application doesn’t use a listener.
First of all—you want to read the official Microsoft guidance here. It can be a little confusing, so here are the basics of what you need to.
- Create temp database—you need to create the Availability Group before the SharePoint install is kicked off, so you want to have a database to include in your AG.
- Build your AG and add your temp database to it. I’m not going to go into a great deal of detail on this, but if you need help check parts 1, 2, and 3 of my series on building an AlwaysOn Availability Group.
- After this is complete—go to Failover Cluster Manager and add a Client Access Point resource to the role for your Availability Group.
When you create the client access point, you will need to assign an IP address to it. Additionally, you will need to get an entry in DNS so that your SharePoint server can talk to the access point. You will see in “Other Resources” in your cluster role in Failover Cluster Manager. Unlike a Listener, this does not require an Active Directory Virtual Computer Object (VCO) to be created.
When you install SharePoint, and have the option to specify your database setting—use the client access point.
After the SharePoint installation is complete, add your SharePoint databases to your availability group, and then synchronize with your secondary. Failovers happen seamlessly once this is complete.
I do have one final note of concern—SharePoint creates a lot of databases, without notifying anyone (different applications in SharePoint create new DBs for themselves). I’m still working on a good strategy to automatically add new SharePoint databases to my Availability Group. I wouldn’t do this in any other application, and feel guilty about doing it here. My thoughts are leaning towards a system trigger that fires on new DB create, and then launches a stored procedure that will take a full backup and add the DB to the AG. That feels really ugly to me—does anyone have better ideas for a cleaner solution?