Clustering
What is a cluster
A cluster is a set of servers connected one each other in a logical, more powerful, unit. You can see clustering as a solution to address problems such as scalability (you add more server to get more computation power) and availability (the impact of the failure of a node is minimized by redundancy). Our cluster solution is based on Hazelcast: it's vendor independent, implements failover maintaining backups of the sessions in different nodes, and offers scalability by letting the administrator simply "drop in" more nodes as needed.
Overview
Every session is "owned" by a node and is backupped in a different one. The effective cluster's memory is thus the half of the total allocated by the JVM. In case of server failure or of a new server joining the cluster, the memory blocks, owners and backups, are rebalanced automatically and nothing is lost. Check the following table for an example:
| ram per node | nodes | total backup size | available memory |
|---|---|---|---|
| 1 GB | 2 | 1 GB | 1 GB |
| 1 GB | 4 | 2 GB | 2 GB |
| 1 GB | 6 | 3 GB | 3 GB |
| 2 GB | 6 | 6 GB | 6 GB |
| 4 GB | 8 | 16 GB | 16 GB |
Requirements
Tomcat is currently the only supported container for clustering.
Every node needs an access to the same filesystem and this is normally achieved by using a NAS.
Although it's recommended to use nodes with the same characteristics, it's possible to add nodes with different configurations in terms of cpu and memory.
A new node can join the cluster at any time simply by starting it in the same network and configuring it with the same cluster name.
Recommended Setup
The basic configuration consist in a frontend node, the cluster, and a NAS to host the filesystem.
Setup every node to mount the NAS folder and assign read/write permission to the user that will run the container. Every node must be able to read and write the same repository.
For the setup of the container the general deployment instructions apply entirely using Tomcat with Java 7+ (8 is recommended). Tomcat clustering / session replication is not required or supported. It's fundamental to specify on each node the same cluster name in com.kv.clusterName and to specify the same NAS folder in com.kv.repository.
Although it's not strictly required, it is recommended to deploy a load balancer in a frontend node configured to forward the requests to the cluster's nodes in round robin. A good choice is NGINX with a patch to support AJP but another similar solution (like HTTPD) can also be used.