2

We have really struggled with our Disaster Recovery processes for our SharePoint farm. I would appreciate any input on improving our current processes. Here is the technology that we're currently using in hope of accomplishing what Microsoft calls a "warm-standby" farm for DR.

  • We have two datacenters. A primary and a secondary.
  • Our SharePoint databases are leveraging SQL Always On groups and asynchronously replicating from our primary datacenter to our secondary datacenter. The Always On groups are utilizing a Windows Cluster.
  • Our SharePoint WFE and APP servers are virtualized and use SAN storage. The LUN that contains the WFE and APP server data is replicated from our primary data center to our secondary data center.

With that said, our plan in the event of a DR situation would be something like this ...

1) Create VM's at DR for the WFE and APP servers. Attach the replicated LUN. 2) Boot the VM's without a network connection. 3) Assign networking information to VM's...Ip addresses and subnetting. 4) Restart VM's with network connection. 5) Run script to make the database at DR the primary database.

I realize this a very simple overview of the process, but I am concerned about a couple of things here. Does Microsoft support this LUN replication for the WFE and APP servers? My understanding is that if your using some sort of VM replication of snapshot technology your config database must be taken into consideration at all times because it is very easy to break your whole farm by incorrectly restoring a VM 'snapshot' and/or restoring the config database. Would it not be easier and more reliable to build new app and wfe servers at DR in the event of a DR situation and then attach the config database that is being asynchronously replicated to DR by SQL Always On?

Any information in general on how we can achieve a 'warm-standby' with the technology mentioned above would be excellent. We are aiming for a 4hr RPO and a 48 hour RTO.

Thanks.

Improve this question

1 Answer 1

Reset to default
0

Create seperate app,wfe servers in Primary DC and Secondary DC and go for stretch farm in below case

Take a look at https://technet.microsoft.com/en-us/library/ff628971.aspx. One thing to keep in mind for a stretched farm is that it requires 1Gbps connection with <= 1ms latency (one-way) between all nodes in the farm. If you cannot meet this, then you will not be able to use a stretched farm. In a vacuum, this gives you ~186 miles

Reference: https://social.technet.microsoft.com/Forums/itmanagement/en-US/2d6719e6-f12d-41c1-8f75-954f2c271486/disaster-recovery-for-sharepoint-2013-farm?forum=sharepointadmin

Improve this answer
1
  • Let's assume I cannot use a "stretched" farm...would I just need to plan for a cold standby farm? In that case, I would assume we would keep a copy of the content databases at the secondary DC via SQL Always On Availability Groups. We would then use a VM templates to re-build the app and wfe at the secondary DC if something were to happen at the primary dc. Then we would be able to make the DR database the primary and point the app and wfe servers to the always on listener. That should allow us to stand the farm up in the event of a DR situation correct?
    – user62257
    Commented Dec 6, 2016 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.