Clustering

An Orchestration solution supports the ability to run multiple nodes of ORS in a single, logical entity called a cluster. With ORS cluster support, you can create a scalable architecture in which the system's capacity can be scaled up.

Clustering Requirements

Deployment of ORS cluster requires that:

• Each ORS Node in a cluster should serve the same T-Server/SIP Server.

• Each ORS Node should work with the same persistent storage.

• Each ORS Node should have only one Universal Routing Server in its Connections list.

Note: ORS 8.1.3 cluster deployment allows each ORS Node to have its own Universal Routing Server.

The figure below shows a simple two-Node pair in a cluster.

 

The above figure illustrates a simple two-ORS Node cluster deployment. It shows four ORS instances configured as two Nodes (Primary/Backup ORS applications). Each Node is running on a separate Host. Each node connects to the same T-Server. Each ORS Node connects to the same URS.

Configuring a Cluster/ORS Node

See the section on Configuring an ORS Cluster in General Deployment.

Enhanced Orchestration Cluster Configuration

Starting with release 8.1.400.64, you can configure an ORS cluster using a dedicated Transaction object of type List. In addition, options for all ORS applications in a cluster may be configured within that object. This eliminates the need to individually configure the options in every ORS application.

Configuring the Transaction List Object

1. Create a Transaction List object.
   1. For a multi tenant deployment, create a Transaction List object under the Environment tenant. For a single tenant deployment, create a Transaction List object under the Resources tenant.
   2. Assign an arbitrary cluster name, such as ORS_Cluster_1.
2. In the Annex tab, add the section cluster.
   1. List the cluster nodes/data centers in the same way as in the legacy implementation.
   2. For the Name, specify the name of the ORS Application.
   3. For the Value, specify the Data Center name.
3. Create the sections for option values. Use any one of the following sections: orchestration, scxml, persistence, elasticsearch, performance-alarms, and mcr.
4. Define the options and values for each section.

Sample List Object

The image below shows an example of the Transaction List object sections in Configuration Manager.

Retrieval of Cluster/ORS Application Option Configuration

• Submit the cluster name to ORS as an additional parameter in the command line, -cluster <cluster name>. Upon startup, ORS retrieves the cluster option' configuration from the Transaction List object with that name. Example: -host <host> -port <port> -app <ORS application name> -cluster <cluster name>.
• If the cluster name is defined in the command line, ORS retrieves the configuration options from the Transaction List object. If the same option is configured in both the ORS Application object and the cluster Transaction List object, the option from the cluster Transaction List object takes precedence.
• If the cluster name is not defined in the command line, ORS retrieves options from the ORS Application object(legacy method).

Limitations

• The [log] and other logging-related sections cannot be configured in the cluster transaction list object.
• The scxml\system-id option cannot be configured in the cluster transaction list object.

Transaction List Object Documentation

For information on configuring List objects in Genesys Administrator, see:

• Genesys Administrator Help, Transactions.