Synchronising Service Applications Between SharePoint Disaster Recovery Farms

A key part of hot-standby/disaster-recovery SharePoint 2013 farms is the principal that only content is synchronised between the two farms. The reason being is that we want to reduce the chance that a failure will replicate over to the other farm too, so we just replicate content and keep services separate in each farm.

This is what I mean by SharePoint disaster-recovery & content-syncing, on a basic level:

On failover to the other site, the previous backup becomes the active & gets full read/write access, and the old primary goes into read-only mode (and our users are happy they don’t have an outage):

The question of what exactly to sync for the “content” however isn’t such a black & white principal; some service applications have to be replicated in lockstep with content to maintain data integrity and others don’t, depending on what you use.

What Constitutes Content Replication Exactly?

You would think that is an easy question to answer, but actually it’s not. “Content databases” would presumably be the answer and yes, of course those but the problem is there are other places for “content” and there are dependencies between service-applications to take into account.

What Databases Should Be Replicated then?

If you have any doubts, then I’d say “all except search”. It may not be necessary though; for example, term-sets are often heavily used to tag items; provide friendly URLs for pages, etc, etc. So managed-metadata probably needs to be in lockstep with your content-databases.

User profiles is another one. Are user-profiles something that you let users update on their own? If so that’ll also need to be data-synced between farms, the same way content-databases are. Also remember; you can add managed terms as custom user-profile properties so again, in this instance you’ll need lock-step with managed-metadata/user-profile databases.

External content-types is another from Business Data Connectivity Services – you may need to sync BDC databases too.

Secure Store Service is another one; a big one if you use stored passwords.

In short, anywhere there are cross-references from one service-application to another service-application is where you need to replicate both in lockstep. The responsibility to make you you’re synchronising the right data is entirely yours!

What Service Applications Can I Definitely Not Have to Replicate?

So you’ve seen the above list of databases to “possibly maybe have to keep in lockstep” and are now thinking “well I’ll just sync all the DBs then – what’s the point in having a separate farm?”. You’re probably now wondering if there’s anything else left you don’t have to keep replicated. Good question.

There are two; configuration DB (obviously, otherwise it would just be the one farm), and search.

Search is a big one; search being so complex by nature often causes the most headaches too, either because of lack of understanding or misconfiguration. The good news is that this massive section of SharePoint definitely doesn’t need to be replicated, so you’ll have the benefit of have two copies of it in case you need to troubleshoot one or the other if you need; all parts of it.

Usage & Health is another. That’s handy because it can generate a lot of data.

Aside from that, any service-application that doesn’t even need any backing databases you can create separately just fine.

With this in mind our DR scenario will look more like this in reality:

All service applications are synchronised and are only ever in read/write mode for one farm, all at once together. AlwaysOn for SharePoint for example will guarantee that the secondary replicas will all be in read-only or read/write mode all at once all together.

But Can X Service Applications Share One Database?

Yes, as long as only one farm has write access at any time. Read-only databases are actually supported on all types of SharePoint databases and service-applications are no exception; the product-group tested each one in both read-only & (obviously) read-write modes.

So yes this is possible. Still not convinced? Well the fact we actually run SharePoint Online this way should convince you; the DR farm has the same databases that the production farms do, just in read-only mode until a failover.

Importantly though, only one farm at any point should ever have full read/write access to any SharePoint database. This is an absolute golden rule that’ll cause a world of pain if you break.

How Can I Synchronise Service-Apps Then?

Read this new post of mine - https://blogs.msdn.microsoft.com/sambetts/2016/03/21/running-sharepoint-service-applications-in-read-only-mode-for-disaster-recovery-farms/

Wrap-Up

As touched on earlier, not many people know that this setup we use for SharePoint Online, so we know it works. That doesn’t excuse you not testing the setup though – please make sure you test with multiple failover tests before going to production!

Cheers,

// Sam Betts