What specific clustering technology can be used with SharePoint 2016 if I want an Active/Passive setup with Production and DR?

Question

We're trying to set up our SharePoint 2016 infrastructure in a sort of cluster with Production as one part and Disaster Recovery (DR) as another in an active/passive configuration. The goal is that if the production server can't be reached, then the network should route traffic to the DR server automatically, but ONLY if the active node fails.

Mind you, we're not looking for load balancing. Our company is small and we really don't have that many concurrent users. The concern here is how do we implement a DR strategy for SharePoint that can flip itself on without needing manual intervention.

My next best thought was to alias the SharePoint servers and, in the case of emergency, just change the IP the alias points to to point at the DR machines in the case of disaster.

Any thoughts or suggestions would be welcome. I have researched Windows Clustering quite a bit, but my confusion is on whether any of those strategies work with SharePoint Server. Also, our infrastructure is all on-premises. We're not hosting anything in the cloud at current and don't really have plans on moving in that direction any time soon.

Answer 1

SharePoint has some special requirements when it comes to Disaster Recovery. While the SQL question is important, it isn't the only one.

When you talk about DR, I'm making the assumption that the DR site is quite some distance away from production (few hundred miles/km or greater). This means that you cannot use any form of synchronous replication. You can use Database Mirroring in async mode (deprecated) or AlwaysOn Availability Groups in async mode (preferred).

You would need two separate SharePoint farms. On the destination side, you would mount all of your databases (sans Config, Admin, and Usage databases which should not be replicated) in a read only state. The Managed Metadata Service cannot consume a read only database and the MMS SA would need to be created once the production farm fails. I would not recommend replicating the Search databases as the index cannot be replicated; instead create a new Search Service in the DR farm and crawl the read-only DR content.

Databases would have to be set to read-write mode during the disaster. This means that you have to take some form of action in the DR farm when the production farm fails.

You also need to think about Web Application URLs. You can certainly have the same URL in prod and DR, but on the DR SharePoint servers you'd need to add hosts file entries to point the DR farm at the DR FE(s).

SharePoint DR is expensive and complex. If the company is small enough and you do not have specific requirements to keep using on-prem SharePoint, I'd strongly suggest going SharePoint Online.

Lots of great info can be found below.

Choose a disaster recovery strategy for SharePoint Server

Disaster recovery best practices and strategies for SharePoint search

Super SQL Server Clusters for SharePoint – Part 1