cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Nintex Newbie

AlwaysOn Fail-over with Disaster Recovery (DR) Farm

Jump to solution

Hi, Connect.  I am working on a project for a high-profile client in New York, NY using on-premises Nintex Workflow 2013 Enterprise, Nintex Forms 2013 Enterprise, and SharePoint Server 2013 Enterprise.  The client is hosting their production SharePoint 2013 farm on-premises.  In the event of failure, they have a secondary, DR (disaster recovery) farm hosted in Microsoft Azure running on virtual machines.  The DR farm is a hot spare farm, meaning it is online 24/7 and maintained just as rigorously as the production farm.  In order to achieve automatic fail-over, the SharePoint content databases are replicated asynchronously from the AlwaysOn group on-prem to the AlwaysOn group in Microsoft Azure.  In Azure, the SharePoint content databases are read-only.  They only become writable in a fail-over scenario.  My client would like to achieve the same level of fail-over with the Nintex content databases.

The main challenge here is to keep the Nintex content databases and SharePoint content databases paired correctly and to prevent data loss and data corruption during a fail-over to the DR farm in Microsoft Azure.  To address this challenge I've compiled a list of questions for the community here to discuss regarding disaster recovery for Nintex Workflow with a hot spare SharePoint farm.

  1. Can a Nintex content database, when in read-only mode, be successfully attached to a SharePoint farm using NWAdmin -o AttachDatabase?
  2. How can one prime the Storage table in the Nintex Configuration database when the SharePoint sites are read-only and the Nintex Workflow site collection feature cannot be deactivated and re-activated?
  3. When the production farm fails, what services must be stopped to prevent Nintex Workflow from writing data into the production AlwaysOn database group?
  4. Should these services also be stopped in DR until a fail-over occurs?
  5. Will Nintex Workflow generate a large number of errors in the DR farm if the Nintex content databases are read-only at the SQL level?
Reply
1 Reply
Nintex Newbie

Re: AlwaysOn Fail-over with Disaster Recovery (DR) Farm

Jump to solution

In case anyone is still curious about this topic, I've posted a full summary of a successful HA/DR setup in the Tech Blog:

Enterprise Workflow High Availability with AlwaysOn 

The answers to the questions above are:

1. Yes, but not if the Nintex configuration database is read-only. Best practice: define your database topology in Farm A before replicating everything to Farm B.

2. Use identical SQL host names (read: aliases) in PROD and DR

3. SharePoint Workflow Timer Server + IIS (you cannot allow the workflow timer service to run in the original farm or allow users to access the web sites otherwise the system may create/process workflow data)

4. Yes, but IIS can and should stay on in the DR farm. SharePoint understands the site collections are read-only and prevents users from editing items which may engage workflows.

5. No

View solution in original post

0 Kudos
Reply