Decisions Disaster Recovery Architecture

Overview

A Disaster Recovery (DR) server is typically a duplicate of the primary server in a different location. In the case of a "disaster" event on the primary server, the DR architecture exists to ensure that the Decisions server maintains uptime, and the data is protected.

High Availability servers are effective for disaster recovery in clustered environments by using a load balancer. In a clustered environment, the servers are typically located in the same data center. Using a load balancer would make it so that if one node in the cluster fails, the traffic of that failing node is redirected to available nodes. 

For more information on clustering, please visit the About Clustering article.

Primary vs. Disaster Recovery Database Connections

Primary Database Connection

The primary connection string from the installation will be the database connection that is used for the main server.

Disaster Recovery / Secondary Connection

The secondary connection string operates as a failover connection in the event that the primary connection string fails. For more information on how to configure this secondary connection string, please visit our Setting a Failover Connection String article.

Configure Decisions as a Disaster Recovery server

In order to configure Decisions as a DR server, at least two Decisions installations will be needed. One of the installations is kept offline but references an MSSQL database with Always-On Replication set for the production server. The connection string applied to the Decisions installer needs to reference the replicated database in the disaster recovery server.

In addition, the keys.dat and databaseid.txt file in the DR server file system must be replaced with the same files from the production environment file system so that it can operate identically in a disaster event. While the DR server is not active, the settings.xml tag for this property should be set to <Offline>true</Offline>. Doing this prevents other users (with the exception of administrators) from logging into the server. 

Step-by-Step Setup

1. Install Decisions to the disaster recovery server on a new database. This will need to have a name that differs from the database used for Always-On Replication.
2. Stop the Decisions Server Service (or IIS App Pool).
3. Run the Decisions installer on the disaster recovery server again and select Edit Settings. Change the Initial Catalog field of the database connection string to match the name of the Always-On Replication database.
4. While modifying the settings, make sure that Offline is set to true.
5. Copy the keys.dat and databaseid.txt files from the production server Decisions Services Manager directory and use them to replace the keys.dat and databaseid.txt files in the disaster recovery server file system.

Additional Notes

If the Decisions server being backed up is a multi-tenant environment, navigate to the DR server settings.xml file and set the <UseInstancePrototype> property to false. Traffic must be diverted to the DR server using the load balancer affiliated with the cluster.

The databaseid.txt file needs to be identical on the production and disaster recovery server as scheduled jobs operate differently if the databaseid.txt file is different from the one present at the time of their creation, even if the database being used is identical. 

Syncing Data To Disaster Recovery Server

Files

For a full and comprehensive list of the recommended files to backup from the Decisions environment, please visit our Decisions & File System Backup article.

Settings.xml File

The configurations in the settings.xml file between the primary server and disaster recovery server must match, with the exception of <Offline>true</Offline>.

File Storage

The files in file storage are saved as regular files. This will require that the IT team of the organization determines the best method of file replication in the DR environment.

Other Files

Keys.dat, Modules Files, Databaseid.txt.