Simul Enterprise servers can be configured in a cluster. This nominates one server as the primary and additional servers can be added as slaves.
This adds more resources to perform document comparisons and allows load balancing the of Simul’s web servers. Simul clusters are designed to add capacity but not redundancy. Slaves can fail without affecting the health of the cluster, but the primary must always be operational.
Clustering should be configured with the assistance of Simul’s support team. The following is intending as a rough guide for what’s involved.
When conducting a fresh Simul installation, select the “Install as Slave” option and proceed to install Simul locally:
This will install only the required services for a slave and will not start Simul until the primary node has been configured.
A slave cannot operate without a primary node and must be configured before starting the services:
The primary node’s IP address (or resolvable host name) must be provided, a worker id which is unique amongst other slaves in the cluster and a cluster key which can be obtained from the cluster configuration on the primary node. The cluster key includes sensitive encryption keys to allow the web servers to communicate and must be kept confidential.
Slaves rely on the primary’s database, messaging and cache services. These must be exposed on the local network but ports must be blocked for external / internet access.
The following ports must be opened on the primary and restricted so that only slaves have access: 6379, 27017, 5672. Ports 80 and 443 should be opened on the primary and slaves to end users.
Simul slaves will fail to start if they cannot communicate via these ports.
In order for a cluster to operate, all documents and temporary storage must be accessible by every server in the cluster. This means the local storage option is not supported for a cluster and you must configure Simul to use Network Attached Storage.
You can configure attached storage at the operating system level and configure Simul to use local storage. Alternatively, Simul can mount a network drive on startup using your configuration:
This can be used for both documents and temporary storage. If this approach is used, Simul will use the SMB protocol to write and read data. By default, this includes a 10 second cache which will prevent changes on one server from being visible to the reset of the cluster for a period of time. To overcome this, the SMB cache must be disabled using the following PowerShell script:
These changes must be applied to each server in the cluster and Simul restarted once disabled.
Each slave runs a Simul web server and comparison engine. In larger installations a load balancer can be configured to distribute load amongst Simul’s servers. Simul’s web application uses a combination of HTTP requests and Web Sockets to communicate.
Most HTTP level load balancers support Web Sockets without additional configuration, but TCP level load balancers will need to ensure sessions are sticky during the Web Socket handshake. This means routing from a client IP address should always end up on the same web server if possible.
System administrators should work with Simul’s support team to ensure their load balancer configuration is appropriate.