Deployment and Configuration Options
- Updated on 03 Dec 2013
- 6 minutes to read
Decisions can be installed in myriad configurations to support different types of applications within the bounds of an enterprise’s unique profile. This guide is intended to help you understand and setup some of the different configuration options based on the way that your company will be using the Decisions platform.
Note: If you are using the Decisions platform as a service from our cloud based offering then the contents of this guide do not apply to you. Decisions maintains all of these configuration options and capabilities in our data center installations to ensure availability, backup, and security.
In the most straightforward installation the Decisions platform is installed on an Application Server and connected to a SQL Server database in the same environment.
Figure 1 - Basic Installation
Application Server Clustering
When multiple application servers are being used with Decisions they are most commonly used with a load balancer as shown in Figure 2 - Multiple App Servers with a Load Balancer. The load balancer acts as a primary point of contact so that all of the application servers look the exact same to any end user. The load balancer internally routes data to each of the servers in the cluster based on criteria configured at the load balancer.
Note: When using a load balancer with Decisions it is important that “Sticky bit” is used meaning that a particular user’s session interacts with the same server within the cluster for the duration of the session.
Figure 2 - Multiple App Servers with a Load Balancer
When installing with a load balancer, all of the Decisions installations should use the exact same portal url, and it should be the url that end users will use to connect to the portal through the load balancer.
Using Multiple Application Servers
Decisions can scale by adding additional Application Servers to the environment to help with the load of users performing tasks in the Decisions portal, or to help with the processing of rules and workflows being invoked by another system. In this configuration you need to use multiple installations of the Decisions platforms running on different servers that are all talking to the same database. This configuration of hardware is supported by Decisions clustering capability. In a Decisions cluster all of the Decisions platform installations are aware of one another and can communicate to keep data in sync between the servers.
In Figure 3 you’ll see multiple Decisions application servers. If you have different user types in a manner that lets you segment users and assign them access to different servers you can use multiple Decisions application servers without having to have a load balancer. This is a very uncommon scenario and in most cases where multiple application servers are being used for user interactions you will need a load balancer.
Figure 3 - Multiple Servers in Simple Configuration
When installing in this configuration you provide the same database connection string to each server during installation.
Each server should be installed with a different portal URL specified in the installer.
In every Decisions installation the database is a critical technical component without which Decisions cannot function. This leads many enterprise customers to install the Decisions database into an existing SQL Cluster environment as shown in Figure 4 - Adding a SQL Server Cluster. A basic introduction to SQL clustering can be found here: http://technet.microsoft.com/en-us/library/ms189134.aspx .
For more information on SQL Clustering please contact a Microsoft certified professional.
When interacting with a SQL cluster Decisions is configured in the normal manner. The fact that the database is being provided by multiple servers is transparent to Decisions and no special considerations must be made during installation and configuration.
Figure 4 - Adding a SQL Server Cluster
When using a database, even with a SQL cluster you have a single point of failure for your Decisions applications: the connection to the database. Decisions provides a way to configure a secondary database connection that is used for a failover scenario. You configure SQL Server to use replication which duplicates database data to an additional logical installation of SQL server. More information about SQL Replication can be found here: http://technet.microsoft.com/en-us/library/ms151847.aspx
A Decisions environment with a replicated SQL installation may look simple as in Figure 5 - App Server with a Failover Cluster Configured.
Figure 5 - App Server with a Failover Cluster Configured
Configuring the Failover Database
When creating the publication for replication, you must enable the following settings on all tables.
Copy non clustered indexes = true
Copy user triggers = true
The following screenshots will show you where in the installation you will need to set these settings.
To setup the fail over database you first install Decisions according to the normal instructions. Once the installation is complete, you re-run the installation tool and choose the option “Edit Settings” as shown in Figure 10 - Edit Settings from Installer. Note: This is simply a convenient way to edit Settings.xml in your installed directory and you can accomplish this same thing manually if you prefer not to re-run the installer.
Once the Edit Settings dialog appears you want to configure a second connection string for the property “SecondayDatabaseConnectString.” Please note to make things easier this setting defaults to the same value you provided for your primary connection string. Note: Because this is advanced capability no connection string builder user interface, like the one used during installation, is provided.
Note: After the changes are saved you do not need to restart the services for the changes to be recognized.
By using both a primary and secondary database you must configure the 'Max Text Replication Size' to allow large data transfers. This setting can be changed to allow any text replication size by running the following script.
EXEC sp_configure 'max text repl size', -1 ;
Note: This must be run on both the primary and secondary database server.
A Final Note about Database Failover
Once the application server fails to connect to the primary connection string and begins communicating with the secondary connection it WILL NOT attempt to restore the connection to the primary database. Because of the potential to be out of sync with transactional data the process of restoring full service to the primary connection must be done manually and requires a restart of the services.
Important Note: we only support transactional replication and you cannot use merge replication.
In order to deal with disaster recovery you simply combine the concepts outlined in this document as shown in Figure 6 - Disaster Recovery Configuration. Installing Decisions application servers in different locations is not difficult, nor is routing traffic to the individual sites. The most important aspect of a disaster recovery configuration is making sure that the database is available to the failover application server. In order to accomplish this Decisions recommends using SQL Replication. More information about SQL Replication can be found here: http://technet.microsoft.com/en-us/library/ms151847.aspx
Figure 6 - Disaster Recovery Configuration