Server redundancy requires additional licenses.

System Architecture

The system architecture for redundancy is as follows.

Note the following.

1When you load balance with a web server or L4 switch, configure it to always send requests from the same session to the same server.

2For redundant servers, you cannot use the default databases, H2 or Apache Derby. You must use Oracle Database, Microsoft SQL Server, MySQL, or a similar database.

3For redundant servers, you must use NAS (Network Attached Storage) for the data and backup directories.

Setting Up Redundancy

Prerequisites

Prepare the following.

A web server or L4 switch for load balancing
A database
NAS disk

Installing ManualWorks

Install each ManualWorks instance as described in the Installation Guide.

Configuring the server.xml File

Note the following when you configure the 3RABBITZ_HOME/tomcat/conf/server.xml file.

Keep the 2HTTP Connector as well as the 1Connector for the load balancer (web server). Tasks such as software updates must be done through the HTTP Connector, and it is also used for synchronization between the redundant servers.
When Apache web server acts as the load balancer, set the 3jvmRoute attribute on the Engine tag for sticky sessions. Set a different value on each server.

Configuring ManualWorks

Set the following startup options. For how to set startup options, see this guide.

Set the addresses of the other servers, including their HTTP port numbers, with the 3rabbitz.peer_nodes startup option. For example, set the following on ManualWorks 1.

3rabbitz.peer_nodes=192.168.0.2:1975

Set the following on ManualWorks 2.

3rabbitz.peer_nodes=192.168.0.1:1975

Change the IP addresses and port numbers to match your environment.

If there are three or more servers, list the addresses of all other servers separated by commas (,). For example, set the following on ManualWorks 1.

3rabbitz.peer_nodes=192.168.0.2:1975,192.168.0.3:1975

You can add http:// or https:// before each address. Without it, http:// is used.

With the 3rabbitz.main_node startup option, set one of the redundant servers as the main server. Schedulers run only on the main server.

3rabbitz.main_node=true

Restart after you set the startup options.

Configuring the Load Balancer

Each load balancer is configured differently, so follow the guide for your load balancer. When you configure it, set up sticky sessions through session affinity so that all requests in the same session are handled by the same server.

Keeping Users Logged In Across Nodes

In a redundant environment, ManualWorks stores users' login state in the database and shares it across nodes. Even if one node fails and requests go to another node, users do not need to log in again.

Note the following.

Logging out on one node also logs the user out on the other nodes.
If a node fails and the user is inactive for longer than the session timeout, the login does not carry over to another node. In that case, the user logs in again.
This behavior applies starting with ManualWorks 6.0.26. In earlier versions, users must log in again when requests go to another node.

Only the login information (user ID) is stored in the database. ManualWorks handles other user state in the database rather than in sessions, so separate session replication is not needed.

Notes

You must connect to each server individually for the following tasks.

Updating the license key
Software updates
Checking server properties
Checking log files
Scheduler settings (check on the server set as the main server)

Synchronization requests between nodes are signed, and their sending time is also checked. If the clocks of the nodes differ by more than an hour, synchronization is rejected, so keep the clocks in sync with NTP.

Update all nodes to the same version at the same time. Synchronization requests from nodes running a version earlier than ManualWorks 6.0.26 are rejected because they are not signed, so if you update the nodes one at a time, the caches between nodes are not synchronized in the meantime.