Contents x
Setting Up A Cluster
  • 09 Apr 2024
  • 6 Minutes to read
  • Print
  • Dark
    Light
Contents

Setting Up A Cluster

  • Updated on 09 Apr 2024
  • 6 Minutes to read
  • Print
  • Dark
    Light
Article Summary

A Cluster is a configuration of one or more Decisions Application Servers running on the same Database backend. The Servers work together to appropriately distribute load/work so that one Server is not over or underutilized. The most common configuration is to have a Load Balancer sit in front of two Decisions Servers that distribute work to those Servers.

Additional Documentation 
For more information on Clustering, please refer to the About Clustering article.
For more information on Deployment Configurations, please refer to Deployment Configuration Options.

Setting Up A Cluster (Self Hosted)

Prerequisites
To set up a Self Hosted Cluster,the following is required:
  • Latest .NET Core (Version 7.0 - 7.1) or .NET 5 (Version 7.2+)
  • An existing SQL Server
  • Both Windows Servers with the same Time Zone settings
  • A network device or shared storage accessible to both servers
The Decisions Servers will need to have fully configured certifications for this setup. In addition, a fully configured Load Balancer will be needed.
  1. Install a Decisions environment on each Server. Ensure that both Servers are pointed to the same Database Server and apply the appropriate Licenses on each Server. 
  2. After installing the second Server, remote into both Servers and configure the following settings in tandem; open DecisionsServerInstaller.exe and click EDIT SETTINGS to open the Settings.xml.
  3. In the Settings window, provide a matching FileStorageLocation so both Servers will have full permission to store files. The FileStorageLocation must match since the Keys.dat and PortalPublicKey.key files will autogenerate via FileStorageLocation > Settings. If both Servers cannot view these files in this shared folder, they cannot connect.
  4. Set the ClusterAddressableIP to the Machine IP (e.g. 192.168.10.100) on each Server, respectively. If the Platform is hosted on a special Port or cannot connect to the Server with just the ClusterAddressableIP, set the ClusterPortalBaseURL to the URL of the respective Node in a format of http://[SystemIP]:[Port] (e.g. http://192.168.10.100:8085).
  5. Set the PortalBaseUrl to the URL of the Load Balancer. This will be FQDN for the Server.
    If SSL is terminating, then the ForceBaseURI line will need to be configured with the below code example in the Settings.xml file, located at C:\Program Files\Decisions\Decisions Server\Settings.xml.
    <ForceBaseURI> HTTPSAddress </ForceBaseURI>

  6. Via C:\Windows\System32\drivers\etc\hosts, configure a Host File Entry on both Servers to resolve the Load Balance DNS Name to 127.0.0.1.
  7. Log into the Studio for each Server. Navigate to and open System > Settings > Cluster Settings. From the Edit Clustering Settings window, enable Turn On Clustering, and provide the Redis Base URL. Click Save.
  8. Lastly, Restart the Decisions Server either via RESTART SERVICE Installer or through Services.msc.
    Use HTTP Issue
    The Use HTTPS setting should be disabled before proceeding with the Cluster setup. If this setting is required, please contact the Support Team before proceeding. 

Setting Up A Cluster (IIS Hosted)

Prerequisites

In setting up a clustered environment, two or more Windows Servers will need to be fully configured with all of the following dependencies:

  • IIS (Dynamic Compression must be enabled if IIS Hosted)
  • Latest .NET Core
  • An existing SQL Server
  • Both Windows Servers with the same Time Zone settings
  • A network device or shared storage accessible to both servers

The Decisions servers will need to have fully configured certifications for this setup. In addition, a fully configured Load Balancer will be needed.

  1. Ensure that all prerequisites have been met for an IIS Cluster.
  2. Follow each step outlined in the prior Self Hosted example, being sure to install each environment as IIS Hosted instead.
  3. When configuring the <ClusterPortalBaseURL>, append the virtual directory /decisions/ to it (i.e. [ClusterNodeDomain]/decisions/).

Service Account and Shared Storage Considerations

Decisions will need to be configured (either via DecisionsServerInstaller.exe or in Windows Services) to run as a Service Account. Note that both servers need to be running the same Service Account; this allows the servers within that Cluster to access a Network Shared Drive. In some File Storage (IIS) configurations, the same Service Account running Decisions Server will also need to be configured in the Application Pool Identity. This can be done in IIS Manager via Application Pools > Advanced Settings > Identity.


Azure File Storage 

If Azure is being used as the location for the Shared File Storage, the UNC File Storage path should bare similarity to "\\ServerName\testfileshare\filestorage\". Before using Azure File Storage for storage on a Cluster, complete the following:
  1. Set up a Local Account.
  2. Provide the Account with a Username that matches the one used for the Azure File Storage Account and a Password containing a value that matches the Azure Storage Account's Key. 
  3. Change the Account Settings so that the Password does not expire and that users cannot change the Password.
  4. Add the Account to the IIS_IUSRS Group. 
  5. Set the App Pool running Decisions to run under this Account.

Steps To Validate (For Both Hosting Types)

It is important to validate the steps that were followed in the previous section. 

  1. Go to each Server and ensure that the Portal can be logged into from HTTP (unless intentionally removed) and HTTPS in a local browser session.
  2. Log in to each Server in the Cluster and verify that each one can write a file to the Shared File Storage. 
  3. Check Load Balancer Timeout: try adding a document to a Folder over 100MB and see if it trips the LB Timeout threshold.
  4. Go through the Load-Balanced URL, locate the Servers Report, and then find the server that has Is Me set to True to affirm which Server the Administrator is currently on. Turn this Server off and ensure that the redirection goes to the other (still active) Server after the timeout duration configured in the Load BalancerSettings has passed.
  5. Now, make sure the Load Balancer Health Check settings are up. Turn one Server off and ensure that it becomes red or negative on the Health Check Report, then repeat these same steps with any additional Servers. Begin turning back on each Server to ensure they return to a healthy state when online.
  6. Remote into each Server, then open a browser and ensure that the IP Address of the other nodes in the Cluster can be reached. Repeat this process for every node in the Cluster to ensure each node can reach the Login Page for every other node in the Cluster from a local browser session.
  7. Add/update an Account on one node. Log in to the other node and make sure the changes appear there too.

       Cluster Validation-14112019-030819.zip  

  8. Go to a node in the Cluster, log in to the Decision Studio, navigate to the MyApps Folder, and create a new Flow. Log out and go to each additional node in the Cluster to confirm that this Flow also exists in the MyApps Folder when going straight to them.
  9. Then while in the MyApps Folder, create a new Flow that sends an email. Go straight to each node to ensure that the appropriate party receives the email sent from each local Flow run.

Updating a Decisions Cluster (For Both Hosting types)

Decisions Clustered environments supports rolling upgrades in minor version upgrades ONLY and requires testing in non-production clusters; this involves taking one Server offline at a time, preventing service interruption, to perform the following actions.

1. Stop Decisions Server or iisreset /stop.

2. Run the Decisions Installer.

3. Start Decisions Server or iisreset /start (Once all Servers have been updated).

For more information on how to update decisions, review the updating Decisions document.

Best Practices

When using the <ClusterPortalBaseUrl>

  • It is not required by default, but if not specified, the cluster will default communication to http://<ClusterAddressableIP> (The ClusterAddressIP iPv4 address can be obtained by running the ipconfig command in CMD/PS on the server).
  • If specified, Decisions will use it for communication and ignore ClusterAddressableIP.
  • If HTTP is available, it can be left blank with no issues.
  • If each node uses a valid certificate (not self-signed, for example, since the other node can't validate the cert for the first node if the other self-signed cert isn't moved over properly) and the HTTPS traffic is the only exposed method, then the HTTPS DNS name would need to be used instead.
  • Can never be the same as <PortalBaseUrl>

How .connected files affect clusters

  • If there are a lot of .connected files in the shared file storage location, there may be an issue with the cluster configuration. These files are used as Heartbeat data to report if a Platform Server is connected to the cluster or not.
  • A lot of .connected files would also increase the platform_server table. New files are generated when details cannot be matched from the machine with the data in the platform_server table.
  • The naming schema of the files should be [platform.server.id].connected
Was this article helpful?
What's Next
Decisions
Resources
Organization
Connect