Setting Up Server Clustering
- Updated on 05 Mar 2019
- 4 minutes to read
You can set up Decisions in a clustered server environment. A Decisions server in a clustered environment shares a database with the other servers but still retains its own file system.
Clustering lets your servers work with each other to provide failover, increased availability of your applications, and load balancing. Failover can be set to active/active or active/passive in the event of a server failure.
To set up server clustering, navigate to the System > Settings folder, selectClustering Settings and select the Edit Clustering Settings action. Select the Turn On Clustering checkbox, define the servers that will be part of the cluster, and then click Save .
- Load balancing is an important component in a clustered Decisions environment. Not using load balancing may result in only the primary server being engaged, negating much of the benefit of clustering.
- Flow editing is not technically supported in a load balanced environment. However, it can work if Sticky Session is enabled (this ensures that all the changes in a given flow edit session continue to hit the same server).
If you attempt to enter the Designer Studio through a load balancer, you will see the following error:
- After importing into a clustered server, it is important to restart Service Host Manager. (Note: this is a known issue and will be resolved.)
- File references will use the same FileStorageLocation property (as set in settings.xml ). Therefore, this location property needs to point to a shared drive and permissions must be granted to all servers in the cluster.
- Less files - need to manually maintain on both app servers
- Keys.dat - Server admin needs to copy from first server to other application servers in cluster so all app servers have same keys.dat file. Decisions stores the keys on the file system so that the key and encrypted data don't live together and and so they can be managed independently of each other
How to Enable Server Clustering
Begin by navigating to the System > Settings folder.
In the Folder Data panel, selectClustering Settings and select the Edit Clustering Settings action.
In the resulting pop-up, select the Turn On Clustering checkbox.
In Decisions 3.2 and later, clustered servers are automatically defined. Servers that are part of the cluster are the ones sharing the central database. Each server registers itself in the servers table, which is how each member of the cluster knows where to send update notifications.
For Decisions 3.1 and earlier :
A new section will appear containing a list of servers that are members of our cluster. To add a server, click the Add button.
In the resulting Edit object pop-up, define the first of our cluster servers.
In the Name field, type "Server1". In the IP Address field, type the IP address of the first server which will be "192.168.169.136" for the purposes of our example. In the Virtual Directory Path field, type "decisions". The Base Portal URL field will automatically assemble this information into the URL of the portal for this specific machine which, for this example, will be http://192.168.169.136/decisions.
This completes our definition of the first cluster server. Click Save and, back in the Edit Clustering Settings window, click the Add button to add another server.
In the Name field, type "Server2". In the IP Address field, type the IP address of the second server which will be "192.168.168.140" for the purposes of our example. In the Virtual Directory Path field, we will type "decisions". The Base Portal URL field will automatically assemble this information into the URL of the portal for this specific machine which, for this example, will be http://192.168.168.140/decisions.
Clustering is now enabled with the two servers listed above. To save these changes, click the Save button at the bottom of the screen.
If a server in the cluster is using encrypted fields (such as the password field in an Active Directory-integrated environment) , a unique file called keys.dat will be written toC:\Program Files\Decisions\Decisions Services Manager\Instances\Control. This exactfile needs to be present on all app servers in the cluster, otherwise each server will generate its own unique keys.dat file and be unable to correctly decrypt data written by the primary application server. Once created, keys.dat will stay in the same folder and remain unchanged through subsequent upgrades.
To setup a cluster where encrypted fields are used, install Decisions on your primary application server, followed by the rest of your application servers. Copy keys.dat file your primary server to the other application servers, and restart the Service Host Manager service on the other servers. A new keys.dat file may already have been written to the other servers. Replace them with the keys.dat from the primary application server.
Data that has been encrypted using the key from onekeys.dat file cannot be decrypted using any other keys.dat file, so if it becomes necessary in the post-installation period to correct a misconfiguration by replacing keys.dat , be aware that data encrypted through the replaced keys.dat file will not be decryptable by the new one. If the encrypted data is business critical, a process should be implemented to write the unencrypted data to an outside data source (such as a flat file on the app server) , and to read the data back into the system after the new keys.dat file has been installed. If the encrypted data is simple, such as an Active Directory password, you may re-enter and re-save the password after changing thekeys.dat file, and the password will be saved with the correct encryption.