- 19 Feb 2024
- 4 Minutes to read
- Print
- DarkLight
Deployment and Configuration Options
- Updated on 19 Feb 2024
- 4 Minutes to read
- Print
- DarkLight
Overview
Decisions can be installed in myriad configurations to support different types of applications within the bounds of an enterprise’s unique profile. The following guide is intended to help users understand and set up some of the different configuration options based on the way that a company uses the platform.
Decisions maintain all of the following configuration options and capabilities in Decisions' data center to ensure availability, backup, and security.
Basic Installation
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.
Multi-Tenant Installation
In a Multi-Tenant installation, the Decisions platform is installed on a single Primary (Control) Server and interacts with a Database. From this server, additional Instances are broken out into separate individual Instances and Databases.
Application Server Clustering
[PortalBaseURL]/events
path.When multiple Application Servers are being used with Decisions, they are most commonly used 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.
This means that a particular user's session interacts with the same server within the Cluster for the duration of the session.
Installation
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 be scaled 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 Flows being invoked by another system. This configuration uses 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.
The diagram below demonstrates two groups using multiple Application Servers. If using different user types in a manner that allows segmentation of users and assignment to access different servers, multiple Decisions Application Servers can be used without the aid of a Load Balancer.
Installation
When installing in this configuration, provide the same Database Connection String to each server during installation.
Each server should be installed with a different Portal URL specified by the installer.
Two Node Cluster
This configuration provides high scalability but low availability. In this instance, Group 1 shares its workload with the Scheduled Job Server, while Group 2's workload is passed onto the second Decisions Server.
Two Servers with Optional Load Balancer For Backend Heavy Environments
In a Backend environment, users may utilize a two-server setup with an optional Load Balancer. In this configuration, the first server fields all web requests from its Group of users, and the second server is set up as a Job/Scheduled Job Server.
In this setup, the Scheduled Job Server is always on and configured to receive all the heavy workload/Batch Processing but does not receive any requests.
In turn, in the event of the first Server's failure, an optional Load Balancer may be used to direct web request traffic to the Job Server while the first server is being recovered.
SQL Failover
When using a database, even with a SQL Cluster, users have a single point of failure for their Decisions applications: the connection to the database. Decisions provide a way to configure a Secondary Database Connection that is used for a Failover scenario. SQL Server can be configured to use SQL Replication, which duplicates database data to an additional logical installation of SQL Server.
The diagram below displays how an environment with a replicated SQL Installation would look.
Disaster Recovery
In order to deal with Disaster Recovery, simply combine the concepts outlined in this document as shown in the diagram below. 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.