Version: 7.9

Clustered Installation

What is a Clustered Installation?

A clustered deployment consists of redundant Resolve Actions Pro components installed on multiple machines and configured to act as a single instance. All the Actions Pro components are clustered to provide High Availability (HA) and load balancing, with the exception of RSMQ. For this installation type, all cluster nodes must be in close proximity and may not be distributed geographically.

The clustered setup allows for an increased load on Actions Pro as the various components split the work among themselves. It adds redundancy as individual components and servers can fail without bringing down the whole cluster.

You need to handle any database clustering or high availability outside of Actions Pro.

For a Disaster Recovery installation (geographically distributed or otherwise), see the Disaster Recovery.

For other installation types, see Standard Installation and Upgrade.

Minimum Clustered Installation

At a minimum, a clustered installation consists of:

2 RSMQ instances
In all clustered installations, RSMQ must be installed on exactly two of the machines. Less or more instances are not supported.
3 RSControl instances
3 RSRemote instances
3 RSView instances
3 RSSearch instances

In addition:

RSConsole: This is a command-line utility that can be installed on one or more nodes.
RSMgmt: Each node with at least one Actions Pro component must have RSMgmt installed on it.

The minimum cluster setup looks like the following:

Server Name	RSView	RSSearch	RSControl	RSRemote	RSMQ	RSMgmt	RSConsole
ipaddr1	Y (Primary)	Y	Y	Y	Y (Primary)	Y (Primary)	Optional, but must be installed on at least one node
ipaddr2	Y	Y	Y	Y	Y (Secondary)	Y	Optional, but must be installed on at least one node
ipaddr3	Y	Y	Y	Y	N	Y	Optional, but must be installed on at least one node

Common Clustered Installation Types

While clusters can be split out to as granular as one component (and RSMgmt) per server, generally it is easier to only split off components into different servers as needed for performance and network organization reasons. The following are the most common types of clustered installations and the types of usage where they are employed.

note

Each server with at least one Actions Pro component must have RSMgmt installed on it.

note

In all clustered installations, RSMQ must be installed on exactly two of the machines. Less or more instances are not supported.

Cluster Type	Description
3-node cluster	The most basic type of cluster has all components installed across three machines. See Minimum Clustered Installation for a breakdown.
Split RSViews	Requires at least six machines, three for RSView components, and three more for all other components. This cluster type is used in environments where a high number of end users are expected, to give more resources to RSView and make it easier to add RSView instances as needed for end-user growth.
Tiered cluster	Used when different areas of the network must be firewalled off of each other for security reasons. Usually, this cluster type splits UI (RSView) into one tier, control (RSControl and RSMQ) into another, and access (RSRemote) into a third. Often the data tier (DB and RSSearch) is on the same tier as the control.

System Requirements

Actions Pro can scale horizontally for each component. Before you install Actions Pro, read through Architecture Overview e and decide how many servers you need for each component. Keep the following in mind when planning your cluster:

For each core component, decide how many nodes are needed for load balancing and make a note of which server contains which components.
This will come in handy when configuring the Blueprint file for each node.
RSMgmt must be present on each core nodes and RSRemote nodes.
RSMQ must always be installed on exactly two nodes: one Primary and one Backup RSMQ.
RSSearch uses quorum (half the nodes plus one) for electing a master node and changing the Elasticsearch cluster state. Because of that, RSSearch requires at least three instances and, in practical terms, any larger instance count is best kept in the odd numbers (five, seven, an so on).

Core Machines

In a clustered installation, a core machine runs one or more of the core Actions Pro components. RSRemote instances that are required to run on separate remote machines are not considered core machines.

Ensure that the core machines meet the following hardware and software requirements.

Hardware Requirements

The hardware requirements for the core machine type vary depending on your needs. Use the following sizing tables to determine the resources your deployment needs.

Minimum Requirements

At a minimum, a core machine running RSSearch plus other components must meet the hardware requirements presented in the list below.

CPU

4 cores or more, server class

System Memory

Minimum: 16 GB
Recommended: 20 GB

Server Storage

Minimum: 500 GB
Recommended: Depends on usage. As a guideline, scale from 750 GB up. For more information, see Data Management.
Minimum required free space: 20% of the total storage space, but not less than 8 GB.

Machine Sizing Per Core Component

You can choose any number of machines in a clustered configuration as long as it satisfies the minimum node count. You can run different combinations of Actions Pro core component on each machine.

To calculate the machine’s memory and disk space requirements, sum up the individual requirements of the components that you want to run on the machine and add the total to the OS requirements. Use the following table to learn the minimum memory and disk space requirements of each Actions Pro component.

Component	Memory Value	Disk Space
RSControl	1024 MB	1 GB
RSMgmt	512 MB	1 GB
RSMQ	512 MB	1 + (allocated memory) GB
RSRemote	1024 MB	1 GB
RSSearch	4096 MB for operation + 4096 MB to use during upgrades	scale up from 500 GB
RSView	1024 MB	1 GB
RSSync	1024 MB	1 GB
RSLog	1024 MB	1 GB

Software Requirements

Ensure that your core Actions Pro machine have the following software installed.

Java

OpenJDK 11

Linux OS:
- Red Hat Enterprise Linux 7.0
- Red Hat Enterprise Linux 8.0
- Red Hat Enterprise Linux 9.0
  note
  If you are installing or upgrading Resolve Actions Pro on RHEL, you must install OpenSSL 1.1.1. Refer to the instructions here for guidance.
- CentOS Linux 7.0
  note
  Due to an Erlang dependency, the OpenSSL package has to be updated to version 1.0.2 on CentOS 7 versions earlier than 7.4.
- CentOS Linux 8.0

note

While other OSes or OS versions might technically function, currently only the above list is supported for a Resolve Actions Pro installation. If you have a firm requirement to run Resolve Actions Pro on an unsupported system, please contact Resolve Systems through the Resolve Systems Customer Portal at https://support.resolve.io/.

Database Machine

Before you install Actions Pro, you need to bring up one or more machines for the Actions Pro database (DB) and install the DB.

Hardware Requirements

For CPU and memory requirements, see the official documentation of the DB type that you choose to install. Required storage depends on your usage. As a guideline, scale from 20 GB up.

Similarly, if you choose to run the DB in a HA or DR setup, refer to the official documentation for machine sizing and setup information.

Software Requirements

The following DB types are supported:

MySQL 5.7
MySQL 8.0
MariaDB 10.4
Oracle 12c
Oracle 19c

note

While other database products or product versions might technically function, currently only the above list is supported for a Resolve Actions Pro installation. If you have a firm requirement to run Resolve Actions Pro on an unsupported system, please contact Resolve Systems through the Resolve Systems Customer Portal at https://support.resolve.io/.

Client Machine

The machine that you use to access the Actions Pro web interface must meet the minimum requirements.

Hardware Requirements

RAM: 1.5 GB free physical memory for web browser needs.
High-DPI monitors (not-required): On Windows, web browser zoom Level 100% or 125% is recommended to account for default zoom settings.

Software Requirements

To access the Actions Pro web UI, you need to have one of the following web browsers installed on your client machine:

Firefox (Firefox 94+ recommended)
Google Chrome (Chrome 96+ recommended)
Internet Explorer 11
Edge (Edge 96+ recommended)

In your web browser settings, ensure that you have:

JavaScript support enabled
Cookie support enabled

VM Support

When running Actions Pro in a virtual environment, ensure that each virtual machine used by it has dedicated hardware CPU and memory resources not shared with other non-Actions Pro machines.

Load Balancer

For optimal user experience, the load balancer that you run in front of the Actions Pro cluster must support sticky sessions. This way, the user will be able to switch between the cluster nodes without having to re-log in.

Pre-Installation Tasks

The tasks and information in this section aim to ensure that your Actions Pro environment is properly configured before you start the actual Actions Pro installation. Some of the tasks are mandatory while other are optional.

Creating a Linux User for Actions Pro

After bringing up the core machine, you need to create a Linux user who will run the application. We recommend using the resolve name as it is pre-configured in some configuration files, but you can use any username that you want. This Linux user is referred to as "the resolve user" for the remainder of the document.

groupadd resolve
useradd -g resolve resolve
passwd resolve

For machines that will run standalone RSRemote deployments, see the ::title guide.

Create the same user on all core machines.

Unpacking the Installation Package

Your Resolve representative will provide you with an installation package and, optionally, a license file with filenames resembling the following:

resolve-linux64-base-X.X.X.X.tar.gz
name.lic

If you haven’t been provided with a license file, like when you are doing a POC installation, you can still proceed with the installation and use the product with a 90-day temporary license.

Take these steps to prepare the installation package for installation:

Log in to each core machine with the resolve user.
Create an installation directory.
The installation directory is where Actions Pro will run from. The recommended location is under /opt:
```
mkdir /opt/resolve
```
Enter the installation directory:
```
cd /opt/resolve
```
Use your preferred method to transfer a copy of the files to the installation directory.

Unpack the installation package:

tar -xzvf resolve-linux64-base-X.X.X.X.tar.gz

Optionally, delete the .tar.gz package.
```
rm resolve-linux64-base-X.X.X.X.tar.gz
```

Opening Required Ports

The ports in the following table are the default ports used by the various Actions Pro components and software dependencies. Ensure that the ports are open bidirectionally on your OS and or hardware/software firewall.

Service	Port(s)	Protocol	Description
AMQP	4004	TCP/IP	RSMQ (RabbitMQ) uses this port to send and receive messages between Actions Pro components.
JDBC	3306 (MySQL, MariaDB) 1521 (Oracle)	TCP/IP	Used between Actions Pro components and the SQL DB. These are the standard JDDB connection ports. Open only the port for the RDBMS that you use, including on RSRemote machines.
RSSearch	9300	TCP/IP	Actions Pro uses this port to write Automation execution results to RSSearch (Elasticsearch).
HTTP(S)	8080, 8443	TCP/IP	Used by browsers to communicate with the Tomcat server hosting RSView.
RabbitMQ Management	15672	TCP/IP	Used to make runtime configurations to the RSMQ.
TCP	9300	TCP/IP	Used by Actions Pro components to send commands and data.
HTTP	9200	TCP/IP	Used by external tools to gather data on the Elasticsearch status.
EPMD	4369	TCP/IP	Used by the Erlang Port Mapper Daemon for resolution of node names in a RabbitMQ cluster.
RSMQ	15672	TCP/IP	Port that the RabbitMQ management plugin runs on.
RSMQ	25672	TCP/IP	Used by RabbitMQ when running in a cluster.

Setting Up the DB

Make the following settings according to the DB type that you use.

In this section:

MySQL and MariaDB
Oracle
Common DB Configuration

MySQL and MariaDB

Make the following settings on your MySQL or MariaDB server before running the Actions Pro installation.

Database and User Creation

Ask your DB administrator to create a new database and a new user for Actions Pro as follows:

User

Name—Could be any name, but resolve is recommended as this is the name pre-configured for your convenience in the Blueprint file.
Remote access—Ensure that the user is allowed to connect from the external IP where you will be installing Actions Pro.

Database

Name—Could be any name, but resolve is recommended as this is the name pre-configured for your convenience in the Blueprint file.
Permissions—Grant the following permissions to the user that you created for Actions Pro:
- CREATE
- INSERT
- UPDATE
- DELETE

note

The installer can initiate the MySQL/MariaDB database for you if you haven’t done so already before starting the installation. This approach is however not recommended for production use because it grants full privileges to the user over the database. Even with this approach, you still need to create the user account yourself and provide its credentials to the installer.

See the installer’s -u and -p options for details.

It is recommended to validate the user’s access before starting the Actions Pro installation. From the machine where you will be installing Actions Pro, run the following command (subject to additional installation):

mysql -u <DB user> -h <DB server>

Where:

DB user is the username of the user that you created in MySQL/MariaDB.
DB server is the IP address or the hostname of the MySQL/MariaDB server.

If you can’t connect, review the account with the help of the official MySQL/MariaDB documentation and check your firewall settings.

Maximum Allowed Packet

Increase the maximum allowed packet size (max_allowed_packet) to accommodate large file attachments. Use a value two to three times the expected maximum file size. The recommended minimum is 384 MB.

For example, add the following lines to an an option file:

[mysqld]
max_allowed_packet=384M

UTF-8

Ensure that the DB is configured for UTF-8. These are the recommended properties:

[mysqld]
init_connect='SET collation_connection = utf8_general_ci'
init_connect='SET NAMES utf8'
character-set-server=utf8
collation-server=utf8_general_ci

Maximum Allowed Connections

Ensure that enough DB connections are allowed. By default, Actions Pro can open up to 200 DB connections per component. To prevent connection throttling, set the DB’s maximum allowed connections (max_connections) to a higher value.

[mysqld]
max_connections=1850

Use the formula below to calculate the suitable value:

Check the DB pool size per component per node.
Default settings
- rscontrol.sql.maxpoolsize=100
- rsview.sql.maxpoolsize=200
Multiply each pool size by the node type count and sum up the products.
<RSControl DB pool size> * <RSControl node count> + <RSView DB pool size> * <RSView count>
Add 10 extra connections for each core node (nodes that are not running standalone RSRemote deployments): <Core node count> * 10
Add contingency of at least 10 connections for DB administrators to be able to log in manually.

Example 1

3 node cluster with default of 100 connections per component (rscontrol.sql.maxpoolsize = 100, rsview.sql.maxpoolsize = 100)
100*3 + 100*3 + 10*3 = 630
Contingency = 10
Total connections = 640

Example 2

5 node cluster with default of 200 connections per component (rscontrol.sql.maxpoolsize = 100, rsview.sql.maxpoolsize = 100)
200*5 + 200*5 + 10*5 = 2050
Contingency = 10
Total connections = 2060

Concurrent Inserts

Optionally, consider always allowing concurrent inserts. The concurrent_insert system property allows MySQL to insert rows at the end of the table without blocking concurrent queries. The default value is 1, which allows concurrent inserts only if there are no "holes" in the table from deleted rows.

The "holes" occur because rows are archived and purged from the table without optimizing the table. Ensure tables are optimized by using the OPTIMIZE TABLE command when archiving and purging the data.

You can set concurrent_insert to 2 to allow concurrent inserts even when there are "holes" in the table. The disadvantage of this approach is that the table size is not reduced until you optimize it.

Oracle

Make the following settings in your Oracle installation before running the Actions Pro installation.

User Creation

Ask your DB administrator to create a new user for Actions Pro as follows:

Name—Could be any name, but resolve is recommended as this is the name pre-configured for your convenience in the Blueprint file.
Remote access—Ensure that the user is allowed to connect from the external IP where you will be installing Actions Pro.
Configure the database instance for a high number of concurrent transactions.
Configure the database instance for a high number of concurrent connections.
Consider setting an unlimited quota on the schema’s tablespace.
Permissions—Grant the Actions Pro user the following permissions over the resolve schema:
- CREATE
- INSERT
- UPDATE
- DELETE

It is recommended to validate the user’s access before starting the Actions Pro installation. From the machine where you will be installing Actions Pro, start your preferred Oracle remote connection utility and run the following command:

CONNECT <DB user>/<password>@<DB server>

Where:

DB user is the username of the user that you created in Oracle.
password is the password for the of the Oracle user.
DB server is the IP address or the hostname of the Oracle server.

If you can’t connect, review the account with the help of the official Oracle documentation and check your firewall settings.

High Concurrency

When using Actions Pro in a cluster, there can be a high rate of concurrent sessions to the database. It is recommended to increase the Oracle processes to a more suitable value. Use the following command:

alter system set processes=<sessions count> scope=spfile

Where sessions count is the new database sessions limit.

Use the formula below to calculate the suitable value:

Check the DB pool size per component per node.
Default settings
- rscontrol.sql.maxpoolsize=100
- rsview.sql.maxpoolsize=200
Multiply each pool size by the node type count and sum up the products.
<RSControl DB pool size> * <RSControl node count> + <RSView DB pool size> * <RSView count>
Add 10 extra connections for each core node (nodes that are not running standalone RSRemote deployments): <Core node count> * 10
Add contingency of at least 10 connections for DB administrators to be able to log in manually.

Example 1

3 node cluster with default of 100 connections per component (rscontrol.sql.maxpoolsize = 100, rsview.sql.maxpoolsize = 100)
100*3 + 100*3 + 10*3 = 630
Contingency = 10
Total connections = 640

Example 2

5 node cluster with default of 200 connections per component (rscontrol.sql.maxpoolsize = 100, rsview.sql.maxpoolsize = 100)
200*5 + 200*5 + 10*5 = 2050
Contingency = 10
Total connections = 2060

Monitoring Permissions

It is optional but recommended to grant the Oracle user the select permissions over the following tables to aid monitoring by RSMgmt.

grant select on dba_segments to resolve;
grant select on dba_data_files to resolve;
grant select on SYS.V_$SYSMETRIC_SUMMARY to resolve;
grant select on SYS.V_$SYSMETRIC to resolve;
grant select on dba_free_space to resolve;

Common DB Configuration

The settings and requirements listed in the following sections apply to all supported DB types.

Date and Time Synchronization

Ensure that the date and time are synchronized between server machines including the database server machine.

Setting OS Limits

Elasticsearch (RSSearch), part of Actions Pro, typically requires more resources than what is generally allowed by the Linux OS. The installation package provides a pair of pre-installation scripts that can set new resource limits for you: setup_limits.sh and setup_sysctl.sh. Both scripts are located in the installer’s bin directory and require root privileges.

You need to reconfigure the OS limits on the core machine that will run RSSearch.

The setup_limits.sh script sets file limit (nofile), memory limit (memlock), address limit (as), and process limit (nproc) in /etc/security/limits.conf. For more information, check the limits.conf(5) man page.

Run setup_limits.sh as follows:

To set the limits yourself, specify numbers for each of the four limits as command-line parameters, in this order: nofile, memlock, as, nproc.
```
./setup_limits.sh 40000 unlimited 10000 5000
```
To set a limit to the defaults recommended by Resolve, replace it with the --default switch.
Run ./setup_limits.sh --help to see the current default values.
```
./setup_limits.sh --default --default --default --default
```
To skip setting any of the limits, use the respective skip command-line switch: --skip-file, --skip-memory, --skip-address, --skip-process.
```
./setup_limits.sh --skip-file unlimited 10000 5000
```

The setup_sysctl.sh script adds a Virtual Memory Max Map Count (vm.max_map_count) in /etc/sysctl.conf. For more information, check the sysctl.conf(5) man page.

Run setup_sysctl.sh as follows:

To set the value yourself, specify the numbers as a command-line parameter:
```
./setup_sysctl.sh 300000
```
To set the value to the default recommended by Resolve, replace it with the --default switch.
Run ./setup_sysctl.sh --help to see the current default value.
```
./setup_sysctl.sh --default
```

Configuring a Load Balancer

It is recommended to run a load balancer in front of the cluster’s RSView instances to provide a single entry point to the Actions Pro UI and provide seamless operation when an instance experiences downtime.

As a frontend rule, configure the IP address or hostname where you want the Actions Pro web UI to be accessible over HTTPS.
Take note of the hostname/IP address and the port number as you will need to supply them to the Actions Pro installer later on (see the -dns and -port options). This way, the installer will configure RSView to generate internal links using the load balancer URL instead of its own hostname and port number.
As a backend rule, configure the hortnames/IP addresses and port numbers of all nodes that will run RSView.
The default RSView port number is 8443 and can be changed in the Blueprint file before or after installation.

Without a load balancer, you will be able to access each individual RSView server directly at its hostname/IP address.

Setting Up Security Certificates

By default, HTTP connections to Actions Pro are done over a secure connection. If you want to use a specific security certificate, such as a certificate signed by a Certification Authority, make sure you’ve copied the certificate’s keystore to the core machine or machines before you start the installation.

The installer takes command-line options (see the Running the Installation section) that you can use to specify the certificate location. If you don’t provide a certificate, a new keystore will be generated during installation containing a self-signed certificate.

Configuring the Blueprint File

The Blueprint file contains configuration settings such as server names, network addresses, and port numbers that you need to set before installing Actions Pro. It is a plain-text file consisting of name-value pairs. The one shipped with the installations package comes with default values for many of the settings.

You can either modify the included Blueprint file or make a copy and modify that. Later, when running the installer, you can specify the location of the Blueprint file.

After installation, the installation Blueprint file becomes the basis for the permanent Blueprint file.

Take the following steps to prepare an installation Blueprint file:

On each core machine, open the Blueprint file for editing—either open the default blueprint.properties file directly under the installer directory or the copy that you made.
Edit the values of the properties listed in the tables below to match your environment.

Configuring Blueprint files for a clustered setup means that most settings will be the same. For a quicker setup, configure one Blueprint for one of the cluster nodes, then copy it to the remaining nodes and reconfigure only the properties that need to be different between nodes.

Required Blueprint Properties

The following table lists the Blueprint properties that you must set before running the installation:

Property	Description	Default Value
PRIMARY	Whether the node is the Primary node. The Primary node creates DB tables and RSSearch indices and gathers Reporting metrics. Ensure that this is set to `true` on only one of the nodes.	true
CLUSTERNAME	Name of the RSSearch cluster. Set it to be the same between all nodes. Must be unique for a cluster (e.g., PRODUCTION, DEVELOPMENT, TESTING).	RESOLVE
SERVER_ID	The ID for the local server. Set it uniquely between the nodes, always starting from 1 (1, 2, 3,..). On the basic 3-node, using the order from RSVIEW_NODES is recommended.	1
LOCALHOST	The hostname or IP address of the local server. Change to the actual IP address or hostname of the machine. Use the same value in the `*_NODES` properties if RSView, RSSearch, and RSControl is installed on the local machine. The value is automatically set to the output of the `hostname` OS command if left blank.	127.0.0.1
RSVIEW_NODES	Comma-separated list of the hostnames or IP addresses of all nodes running RSView, including the local machine if the component runs on it. Preferably, keep the list order the same between each node’s Blueprint.	127.0.0.1
RSSEARCH_NODES	Comma-separated list of the hostnames or IP addresses of all nodes running RSSearch, including the local machine if the component runs on it. Preferably, keep the list order the same between each node’s Blueprint.	${RSVIEW_NODES}
RSCONTROL_NODES	Comma-separated list of the hostnames or IP addresses of all nodes running RSControl, including the local machine if the component runs on it. Preferably, keep the list order the same between each node’s Blueprint.	127.0.0.1
DB_TYPE	The type of the SQL database that you prepared to work with Actions Pro. Possible values: `mysql`, `oracle`	mysql
DB_HOST	Host name or IP of the machine where the SQL database is running.	127.0.0.1
DB_USERNAME	Username for Actions Pro to use to connect to and write in the SQL DB.	resolve
DB_PASSWORD	Password for DB_USERNAME.	resolve
DB_NAME	The name of the SQL database for Actions Pro to use.	resolve
DB_SCHEMA	The name of the SQL database schema to use. Leave blank to automatically use the DB_NAME (for MySQL) or DB_USERNAME (for Oracle).
DB_URL	JDBC URL to use to connect to the database. If left blank (not recommended), it will be generated from the DB_HOST and DB_NAME based on the DB_TYPE. For more complex cases, such as when enabling SSL, ensure that you have entered the full connection string.	No default Example: `jdbc:oracle:thin:@//127.0.0.1:1521/resolve` or `jdbc:mysql://mysql.example.com:3306/my_database?useSSL=true&serverTimezone=UTC`
RSMQ_PRIMARY_HOST	The hostname or IP address of the Primary RSMQ node. If it runs on the local machine, set to the IP of the local machine.	127.0.0.1
RSMQ_PRIMARY_PORT	Port used by the Primary RSMQ service.	4004
RSMQ_BACKUP_HOST	The hostname or IP address of the Backup RSMQ node.
RSMQ_BACKUP_PORT	Port used by the Backup RSMQ service.	4004
# Installed Componentsresolve.<component>	Choose which Actions Pro components to install on the current node. Components set to true will install on the current node; components set to false will not. The reference to another property (e.g. `${PRIMARY}`, `${resolve.rslog}`) will take the value of that property. Components with `_NODES` list properties are automatically set to false if the `LOCALHOST` property value is not found in the respective `_NODES` list.	resolve.rscontrol=true resolve.rsremote=true resolve.rsview=true resolve.rsmq=true resolve.rsconsole=true resolve.rsmgmt=true resolve.rssearch=true resolve.rssync=false resolve.rslog=${PRIMARY} resolve.logstash=${resolve.rslog} resolve.kibana=${PRIMARY} resolve.rsvault=false resolve.rskeyservice=false

Optional Blueprint Properties

The following table lists Blueprint properties that you may consider setting before running the installation:

note

The hardware requirements listed in System Requirements are based on the default allocations showed in the table. Consider increasing the installed memory accordingly if you increase any of the allocations.

Property	Description	Default Value
resolve.user	Linux user that Actions Pro will run under.	resolve
rsmq.Xms	RSMQ minimum memory allocated in MB.	256
rsmq.Xmx	RSMQ maximum memory allocated in MB.	512
rscontrol.run.Xms	RSControl minimum memory allocated in MB.	256
rscontrol.run.Xmx	RSControl maximum memory allocated in MB.	1024
rsview.run.Xms	RSView minimum memory allocated in MB.	256
rsview.run.Xmx	RSView maximum memory allocated in MB.	1024
rsremote.run.Xms	RSRemote minimum memory allocated in MB.	256
rsremote.run.Xmx	RSRemote maximum memory allocated in MB.	512
rsremote.esb.queue.name.1	Queue name that RSRemote will listen to. The queue will be created if it doesn’t exist. You can add multiple RSRemote queues by duplicating the property with an increasing number (rsremote.esb.queue.name.2, rsremote.esb.queue.name.3, ...) and setting it to a different value. This can be useful if RSRemote needs to be targeted by specific tasks. Alternatively, you can remove all queues if you want the RSRemote to only perform gateway functions.	RSREMOTE
rsmgmt.run.Xms	RSMgmt minimum memory allocated in MB.	64
rsmgmt.run.Xmx	RSMgmt maximum memory allocated in MB.	512
rssearch.run.Xms	RSSearch minimum memory allocated in MB.	4096
rssearch.run.Xmx	RSSearch maximum memory allocated in MB.	4096
rssync.run.Xms	RSSync maximum memory allocated in MB.	1024
rssync.run.Xmx	RSSync maximum memory allocated in MB.	1024
logstash.run.Xms	RSLogstash maximum memory allocated in MB.	1024
logstash.run.Xmx	RSLogstash maximum memory allocated in MB.	1024
rsremote.run.ld_library_path	Full path to a `.so` library file needed for an ActionTask in RSRemote.
search.ttl	How long does Elasticsearch store files, in seconds.	7776000

Advanced Blueprint Properties

The Blueprint file comes with a large number of additional properties that you are advised to leave with their default values for the installation. If necessary, you can tweak them after the installation.

Running the Installation

After you complete all the pre-installation tasks, you are ready to run the installation. The installers in a clustered environment wait on each other and need to be started at roughly the same time to be able to complete successfully.

To run the installation, take these steps:

Open a terminal session to each of the cluster machines as the user that you created to run Action Pro (resolve by default).
On each machine, enter the directory where you unpacked the installation package.
Simultaneously on all machines, start the installation script:
- With the Blueprint file in the default location:
```
./install-resolve.sh blueprint.properties
```
- With a custom Blueprint file in /home/resolve/:
```
./install-resolve.sh /home/resolve/blueprint.properties
```
- With a license file in /home/resolve:
```
./install-resolve.sh blueprint.properties -lic /home/resolve/name.lic
```
- With a SSL/TLS certificate location in /home/resolve:
```
./install-resolve.sh blueprint.properties -keystoreFile /home/resolve/cert -keystorePass pass
```
- If running a load balancer in front of the RSView nodes:
```
./install-resolve.sh blueprint.properties -dns resolve.example.com -port 8443
```
- Optionally, add other command-line options as explained in the table below.
Press Y to accept the license agreement that displays.
Wait for the installation to complete.

Depending on the system, installation may require more than 20 minutes but typically requires less than 10. When the installation process completes, the Actions Pro processes start automatically.

The installer accepts the command-line options described in the table below.

Option	Description
-lic <license file location>	Specifies the location of the license file to use for licensing Actions Pro. You can also license the application later from the Web UI. If you haven’t been provided a license file, for example when you are doing a POC installation, you can still proceed with the installation and use the product with a 90-day temporary license.
-dns <host name>	Hostname or IP address to be used to access the Actions Pro Web UI. Required when using a load balancer in front of RSView. In this case, set to the hostname/IP address of the load balancer. This way, the installer will configure RSView to generate internal links using the load balancer URL instead of its own hostname and port number. The `-dns` and `-port` options are used to set the `system.resolve.url` system property which determines how some response links are created.
-port <port>	HTTP port number to be used to access the Actions Pro web UI. Required when using a load balancer in front of RSView. In this case, set to the port number of the load balancer that will be used to access Actions Pro. The `-dns` and `-port` options are used to set the `system.resolve.url` system property which determines how some response links are created.
-u <MySQL username> -p <MySQL password>	Not recommended for production use When using MySQL/MariaDB for the database and you don’t have the database prepared, provide the login details of a MySQL account that has permissions to drop and create databases. The installer will use the account to create the database for you.
-cu	RSConsole username to run default imports. Only needed if you have changed the default admin credentials in the Blueprint.
-cp	RSConsole password to run default imports. Only needed if you have changed the default admin credentials in the Blueprint.
-keystoreFile	Keystore file path with private key and public certificates for RSView HTTPS configuration. If not provided, a new keystore is generated during installation with a self-signed certificate.
-keystorePass	Keystore password for keystore file. If not provided, a default value is used.
--force	Not recommended Continue installation even if some of the validations fail (for example an existing installation or running components have been detected).
--continue	Resume a failed installation, skipping some duplicate steps such as unpacking the component .tar.gz files.
--http	Install RSView using HTTP instead of the default HTTPS.

Post-Installation Tasks

After the Actions Pro installer completes, it is highly recommended to take steps towards securing the application and making additional settings.

Logging In and Changing the Admin Password

Actions Pro should be fully functional after installation with all its services running. Verify that you can log in to the Web UI as administrator:

Address: https://<server-address>:8443
Default username: admin
Default password: resolve

Upon login, you will be asked to change the default password with a more secure one. Ensure it adheres to the following password policy:

The password must be at least 7 characters long
The password must contain a number
The password must contain a capital letter
The password must contain a special character

Changing the Default RSConsole Password

RSConsole is a utility that allows you to manage various aspects of your Actions Pro deployment from the command-line. After installation, the system provides a default set of credentials for logging in to RSConsole: admin:resolve. It is highly recommended to change the default admin password to a safer one immediately after installation.

Take these steps to change the RSConsole default password:

Open <actions-home>/bin/blueprint.properties for editing.
Set rsconsole.users.user.password.1 to the new password in plain text and save the file.
(Optional) Change the administrator username in the rsconsole.users.user.username.1 property (admin by default).
Stop Actions Pro:
```
<actions-pro-home>/bin/stop.sh all
```
Apply the configuration change:
```
<actions-pro-home>/bin/config.sh
```
Restart Actions Pro:
```
<actions-pro-home>/bin/run.sh all
```

The configuration script replaces the plain-text password that you entered with an irreversible hash.

Changing the Default resolve.maint Password

The resolve.maint user is a super user for the Actions Pro Web UI. It is highly recommended to change the default password for the account immediately after installation.

Use RSConsole to change the resolve.maint user password:

Log in to any of the core machines that have the RSConsole component installed.
Start RSConsole:
```
<actions-pro-home>/rsconsole/bin/run.sh
```
Log in using:
- The default username and password admin:resolve if you haven't changed them in the Blueprint file.
- The new credentials if you have changed them in the Blueprint file.
(Optional) Target a specific RSView instance by connecting to its unique GUID found in <actions-pro-home>/tomcat/webapps/resolve/WEB-INF/config.xml:
```
CONNECT <GUID>
```
If you don’t connect to an RSView instance, the script automatically uses the RSVIEW topic to broadcast the password change to all connected RSView instances.
Change to the config directory:
```
CD config
```
Run the password change command:
```
_SetPassword
```
At the username prompt, enter resolve.maint.
At the old Password prompt, enter resolve.
At the new Password prompt, enter the new secure password, adhering to the following password policy:
- The password must be at least 7 characters long
- The password must contain a number
- The password must contain a capital letter
- The password must contain a special character

A message returns from each RSView instance indicating whether the password change was successful. You can find additional logs in each instance’s rsview.log under <actions-pro-home>/tomcat/logs/.

Changing the Elasticsearch and Kibana Passwords

Actions Pro installs Elasticsearch (RSSearch) and Kibana during deployment with default passwords. It is highly recommended to change those passwords to new, secure passwords after installation.

Take these step to change the default Elasticsearch and Kibana password:

As the resolve user, log in to the machine where you installed RSSearch.
Go to <actions-pro-home>/elasticsearch/bin.
Create an espass file if it does not already exist. For example:
```
vi espass
```
Enter you new password in the file:
- Ensure the file only has a single line with the password.
- Ensure that there aren’t any white spaces around the password.
- Take a note of the password and keep it in a safe place.
Run the password change script:
```
./rssearch-setup-password.sh
```
Remove the espass file:
```
rm ./espass
```
On all core machines, update the Blueprint file:
1. Back up <actions-pro-home>/bin/blueprint.properties.
2. Stop all Actions Pro components:
```
<actions-pro-home>/bin/stop.sh all
```
3. Open <actions-pro-home>/bin/blueprint.properties for editing.
4. Set the same password you used for Elasticsearch to the rssearch.security.user.password Blueprint property.
  - Do not cut and paste the password as this may introduce hidden characters.
  - Replace any original encrypted values if present. The values that you enter will be later replaced with an irreversible hash by the configuration script.
  - The Kibana password property (rsview.kibana.password) uses the same value by default. To set a separate password for Kibana, replace the default rsview.kibana.password value with the actual password.
5. Save the file.
6. Run the configuration script:
```
<actions-pro-home>/bin/config.sh
```
7. Restart all services:
```
<actions-pro-home>/bin/run.sh all)
```

Configuring the Services to Start Automatically

Actions Pro provides a script that can help you set up your Linux OS to start the Actions Pro services automatically on system restart.

The setup_services.sh script creates soft links for the init scripts in the init.d, rc3.d, and rc5.d directories. These soft links are set up to start and stop the Actions Pro services during a system startup or shutdown.

The script needs to be run with root privileges.

Script usage:

To set up all services to start on system startup:
```
<actions-pro-home>/bin/setup_services.sh all
```
To set up a particular service or services to start on system startup:
```
<actions-pro-home>/bin/setup_services.sh <service-name1> [<service-name2> <service-name3> ...]
```
Where service-name can be any of rsview, rssearch, kibana, rsmq, rscontrol, rsremote, rsmgmt, logstash, rssync, and rslog.

To see usage information:

<actions-pro-home>/bin/setup_services.sh --help

Setting Up Email Notifications

Configuring an email server will allow your Actions Pro server to send email notifications. Some features that require setting up an email server ActionTasks using the EmailConnect Java class and resetting a forgotten user password. Actions Pro supports both SMTP and POP3.

Property	Description	Default Value
EMAIL_ACTIVE	Enable or disable email notifications. Possible values: `true`, `false`	false
EMAIL_HOST	IP address or hostname of the email server.
EMAIL_SMTP_PORT	Port number for SMTP communication with the email server.	25
EMAIL_POP3_PORT	Port number for POP3 communication with the email server.	110
EMAIL_USERNAME	Username used to authenticate against the email server.
EMAIL_PASSWORD	Password used to authenticate against the email server.
EMAIL_SSL	Whether to use SSL to secure the communication with the email server. Possible values: `true`, `false`	false

Installing Embedded Python

One of the methods to run Python code in Actions Pro, Embedded Python, requires installing and configuring a Python distribution on the OS. This method allows you to execute Python within the module's JVM as opposed to as an external process. It has the benefit of having access to more parameter bindings. See ActionTask Development.

Installation

Embedded Python depends on a standalone Python installation.

To provision your Actions Pro deployment for Embedded Python ActionTasks, install Python on all Actions Pro nodes running RSControl or RSRemote, including standalone RSRemote instances.

Linux Installation

The supported Python versions on Linux include:

Actions Pro core nodes:
- 3.9.x
Standalone RSRemote:
- 3.9.x

If you are performing the installation through a precompiled package, ensure that you install the development package, for example, python39-devel.x86_64.

Windows Installation

Embedded Python on Microsoft Windows is only supported on standalone RSRemote instances. The supported Python versions include:

3.9.x

Resolve recommends that you install Python to be accessible to all users or at the least to the Local System built-in user account. Doing so will ensure that the RSRemote service will have access to the Python installation.

If you have installed Python for a specific local user other than Local System, then ensure that the RSRemote service's Log on as user account is set to that specific user before restarting the service.

Configuration

After you install Python, let Action Pro know where you installed it.

Take these steps to configure Actions Pro:

On all nodes running RSControl and RSRemote, excluding standalone RSRemote, take the following steps:

Stop all services:

# stop all services
<actions-home>/bin/stop.sh all
# verify all services are stopped
<actions-home>/bin/status.sh all

In blueprint.properties, set the following properties:

# full path to the Python installation directory for use by RSControl
rscontrol.python.embedded.home=/usr/lib64/python3.9
# full path to libpython for use by RSControl
rscontrol.python.embedded.lib=/usr/lib64/libpython3.9.so.1.0
# full path to the Python installation directory for use by RSRemote
rsremote.python.embedded.home=/usr/lib64/python3.9
# full path to libpython for use by RSRemote
rsremote.python.embedded.lib=/usr/lib64/libpython3.9.so.1.0

Apply the configuration changes:

# apply the configuration
<actions-home>/bin/config.sh

Restart the services:

# start all services
<actions-home>/bin/run.sh all

On all standalone RSRemote nodes, take these steps:

Stop all services:

Linux
Windows

# stop all services
<actions-home>/bin/stop.sh all
# verify all services are stopped
<actions-home>/bin/status.sh all

# stop all services
<actions-home>\bin\stop.bat all
# verify all services are stopped
<actions-home>\bin\status.bat all

In blueprint.properties, set the following properties:

Linux
Windows

# full path to the Python installation directory for use by RSRemote
rsremote.python.embedded.home=/usr/lib64/python3.9
# full path to libpython for use by RSRemote
rsremote.python.embedded.lib=/usr/lib64/libpython3.9.so.1.0

# full path to the Python installation directory for use by RSRemote
rsremote.python.embedded.home=C:/Python39
# full path to pythonXX.dll for use by RSRemote
rsremote.python.embedded.lib=C:/Python39/python39.dll

Apply the configuration changes:

Linux
Windows

# apply the configuration
<actions-home>/bin/config.sh

# apply the configuration
<actions-home>\bin\config.bat

Restart the services:

Linux
Windows

# start all services
<actions-home>/bin/run.sh all

# start all services
<actions-home>\bin\run.bat all

Validating Production Use Cases

Between releases, Resolve makes regular changes to the JAR files that are part of Actions Pro to introduce new functionality and to provide the latest stability and security updates. As an Automation Developer, this can impact use cases that you are migrating from an existing deployment to a freshly installed deployment. Identify your use cases and validate full functionality before you upgrade your production environment(s).

Verify the following use cases:

Automations
Dashboards

Check what JAR files have been updated between your Actions version and the version that you are upgrading to:

Download JAR File Updates Between Versions

Adding Components to a Running Cluster

You can add RSView, RSSearch, or RSControl instances to an existing cluster as load increases. Adding instances requires reconfiguring all existing core nodes. Each reconfiguration involves a restart, that is why it is recommended to reconfigure one node at a time to prevent downtime.

Adding RSRemote instances does not require reconfiguration of the core nodes. See RSRemote Standalone Installation for details.

You cannot add RSMQ instances in a cluster as their count must always amount be exactly two.

When to Add New Components to a Cluster

You might need to add new instances of the various Actions Pro components in a cluster as usage increases to help alleviate the load on the existing instances. Follow the following general guidelines:

Add RSView instances as the number of end-users increases.
Add RSControl and RSRemote instances as the number of automations increases.

Admin reports (see Reports) are the most useful tools for determining when the load on the different components is high enough to require additional resources to be added to the cluster. Before you do that, however, it might be worth it to first increase the memory allocation of the various components to increase performance before adding additional component instances.

Adding a Component to an Existing Node

When adding a new RSView, RSSearch, or RSControl instance to an existing cluster, you need to reconfigure all current nodes to reflect the new instance in the respective *_NODES Blueprint properties.

Take these steps to add components to an existing node:

Reconfigure the local node:
1. As the resolve user, log in to the machine where you want to add components.
2. Open <actions-pro-home>/bin/blueprint.properties for editing.
3. In the # Installed Components section, set the resolve.<component> property for the component that you want to add to true.
4. Update the node lists:
  - If adding RSView, add the local IP address to the RSVIEW_NODES property.
  - If adding RSSearch, add the local IP address to the RSSEARCH_NODES property.
  - If adding RSControl, add the local IP address to the RSCONTROL_NODES property.
5. Save the file.
6. Stop all Actions Pro components:
```
<actions-pro-home>/bin/stop.sh all
```
7. Run the configuration script:
```
<actions-pro-home>/bin/config.sh
```
8. Start all services:
```
<actions-pro-home>/bin/run.sh all
```
Reconfigure all other core nodes:
1. As the resolve user, log in to each of the other core machines.
2. Open <actions-pro-home>/bin/blueprint.properties for editing.
3. Update the node lists:
  Preferably, keep the list order the same between the nodes.
  - If you added RSView, add the IP address of node where you added it to the RSVIEW_NODES property.
  - If you added RSSearch, add the IP address of node where you added it to the RSSEARCH_NODES property.
  - If you added RSControl, add the IP address of node where you added it to the RSCONTROL_NODES property.
4. Save the file.
5. Stop all Actions Pro components:
```
<actions-pro-home>/bin/stop.sh all
```
6. Run the configuration script:
```
<actions-pro-home>/bin/config.sh
```
7. Start all services:
```
<actions-pro-home>/bin/run.sh all
```

Adding a Component to a New Node

When adding a new node to the cluster to run RSView, RSSearch, or RSControl, make a fresh installation while keeping the consideration in this section.

Take these steps to add a new node to an Actions Pro cluster:

Bring up a new machine according to the System Requirements and Pre-Installation Tasks sections.
Configure the installation Blueprint file while keep the following in mind:
- The node must run RSMgmt in addition to any other service that you install.
- The node cannot run RSMQ if you already have two RSMQ instances in the cluster.
- Don’t forget to update the *_NODES properties with the IP addresses of the existing nodes.
Run the installation while keeping the following in mind:
- You don’t need to provide a license file if you have already licensed the cluster on another node.
Run the Post-Installation Tasks while keeping the following in mind:
- When Changing the Elasticsearch and Kibana Passwords, only perform the Blueprint configuration, using the same password as for the other RSSearch nodes.
Ensure that the services on the new node are running:
```
<actions-pro-home>/bin/status.sh all
```
Reconfigure all other core nodes:
1. As the resolve user, log in to each of the other core machines.
2. Open <actions-pro-home>/bin/blueprint.properties for editing.
3. Update the node lists:
  Preferably, keep the list order the same between the nodes.
  - If you added RSView, add the IP address of node where you added it to the RSVIEW_NODES property.
  - If you added RSSearch, add the IP address of node where you added it to the RSSEARCH_NODES property.
  - If you added RSControl, add the IP address of node where you added it to the RSCONTROL_NODES property.
4. Save the file.
5. Stop all Actions Pro components:
```
<actions-pro-home>/bin/stop.sh all
```
6. Run the configuration script:
```
<actions-pro-home>/bin/config.sh
```
7. Start all services:
```
<actions-pro-home>/bin/run.sh all
```

Installation Troubleshooting

Use the information in this section to resolve common issues that may occur during installation.

Unable to Log In as Admin

The installation has finished but I am unable to login to the Web UI as the administrator (user admin).

Probable Cause

Some of the packages were not imported or were imported incorrectly.

Possible Resolution

Perform the following steps:

Log in to a core Actions Pro machine where RSConsole is installed.
Start RSConsole:
```
<actions-pro-home>/rsconsole/bin/run.sh
```
Log in using:
- The default username and password admin:resolve if you haven't changed them in the Blueprint file.
- The new credentials if you have changed them in the core Blueprint file.
Run the following import command:
```
impex/ImportModule users
```
Quit RSConsole:
```
quit
```

Track the RSView logs for the end of the import:

tail -f <actions-pro-home>/tomcat/bin/rsview.log

After the import completes, try again to log in to the Web UI as admin.

If you are still unable to login or are missing menus/tasks after login, perform the following steps:

Log in to the Web UI using the resolve.maint user and the followging password:
- The default password resolve if you haven't changed it using RSConsole.
- The new credentials if you have changed them using RSConsole.
Navigate to the following URL:
https://<hostname>:8443/resolve/jsp/rsclient.jsp#RS.impex.Main.
Do the following with each .zip file located in the <actions-pro-home>/rsexpert directory:
1. Click Upload and select the .zip file.
2. Select the new upload in the list and click Import.
3. In the dialog box that opens, click Import again.
Log out with resolve.maint and log in with admin.

What is a Clustered Installation?​

Minimum Clustered Installation​

Common Clustered Installation Types​

System Requirements​

Core Machines​

Hardware Requirements​

Minimum Requirements​

Machine Sizing Per Core Component​

Software Requirements​

Database Machine​

Hardware Requirements​

Software Requirements​

Client Machine​

Hardware Requirements​

Software Requirements​

VM Support​

Load Balancer​

Pre-Installation Tasks​

Creating a Linux User for Actions Pro​

Unpacking the Installation Package​

Opening Required Ports​

Setting Up the DB​

MySQL and MariaDB​

Database and User Creation​

User​

Database​

Maximum Allowed Packet​

UTF-8​

Maximum Allowed Connections​

Example 1​

Example 2​

Concurrent Inserts​

Oracle​

User Creation​

High Concurrency​

Example 1​

Example 2​

Monitoring Permissions​

Common DB Configuration​

Date and Time Synchronization​

Setting OS Limits​

Configuring a Load Balancer​

Setting Up Security Certificates​

Configuring the Blueprint File​

Required Blueprint Properties​

Optional Blueprint Properties​

Advanced Blueprint Properties​

Running the Installation​

Post-Installation Tasks​

Logging In and Changing the Admin Password​

Changing the Default RSConsole Password​

Changing the Default resolve.maint Password​

Changing the Elasticsearch and Kibana Passwords​

Configuring the Services to Start Automatically​

Setting Up Email Notifications​

Installing Embedded Python​

Installation​

Linux Installation​

Windows Installation​

Configuration​

Validating Production Use Cases​

Adding Components to a Running Cluster​

When to Add New Components to a Cluster​

Adding a Component to an Existing Node​

Adding a Component to a New Node​

Installation Troubleshooting​

Unable to Log In as Admin​

Probable Cause​

Possible Resolution​

What is a Clustered Installation?

Minimum Clustered Installation

Common Clustered Installation Types

System Requirements

Core Machines

Hardware Requirements

Minimum Requirements

Machine Sizing Per Core Component

Software Requirements

Database Machine

Hardware Requirements

Software Requirements

Client Machine

Hardware Requirements

Software Requirements

VM Support

Load Balancer

Pre-Installation Tasks

Creating a Linux User for Actions Pro

Unpacking the Installation Package

Opening Required Ports

Setting Up the DB

MySQL and MariaDB

Database and User Creation

User

Database

Maximum Allowed Packet

UTF-8

Maximum Allowed Connections

Example 1

Example 2

Concurrent Inserts

Oracle

User Creation

High Concurrency

Example 1

Example 2

Monitoring Permissions

Common DB Configuration

Date and Time Synchronization

Setting OS Limits

Configuring a Load Balancer

Setting Up Security Certificates

Configuring the Blueprint File

Required Blueprint Properties

Optional Blueprint Properties

Advanced Blueprint Properties

Running the Installation

Post-Installation Tasks

Logging In and Changing the Admin Password

Changing the Default RSConsole Password

Changing the Default resolve.maint Password

Changing the Elasticsearch and Kibana Passwords

Configuring the Services to Start Automatically

Setting Up Email Notifications

Installing Embedded Python

Installation

Linux Installation

Windows Installation

Configuration

Validating Production Use Cases

Adding Components to a Running Cluster

When to Add New Components to a Cluster

Adding a Component to an Existing Node

Adding a Component to a New Node

Installation Troubleshooting

Unable to Log In as Admin

Probable Cause

Possible Resolution