Installing eXo platform in cluster mode should be considered in the following cases:
Load Balancing : when a single single server node is not enough to handle the load
High Availability : when you want to avoid a single point of failure by having redundant nodes
These characteristics should be handled by the overall architecture of your system. Load Balancing is typically achieved by a front server or device that distributes the request to the cluster nodes. Also, high availability on the data layer can be typically achieved using the native replication implemented by RDBMS.
In this chapter, we will cover only the changes needed by eXo to work in a cluster.
In eXo Platform, the persistence mostly relies on JCR, which is a middleware between the eXo applications (including the portal) and the database. Hence this component must be configured to work in cluster.
The embedded JCR server requires a portion of its state to be shared on a file system shared among cluster nodes :
the values storage
the index
We strongly advise the use of a mount point on a SAN.
The switch to a cluster configuration is done in configuration.properties
First, switch the JCR to cluster mode:
gatein.jcr.config.type=cluster gatein.jcr.index.changefilterclass=org.exoplatform.services.jcr.impl.core.query.jbosscache.JBossCacheIndexChangesFilter
This will tell the JCR to enable automatic network replication and discovery between other cluster nodes.
Next, configure the path for the shared filesystem :
gatein.jcr.storage.data.dir=/PATH/TO/SHARED/FS/values gatein.jcr.index.data.dir=/PATH/TO/SHARED/FS/index
The path is shared, so all nodes will need read/write access to this path.
The cluster mode is preconfigured to work out of the box. It relies on the JBoss Cache configuration.
# JCR cache configuration
gatein.jcr.cache.config=classpath:/conf/jcr/jbosscache/${gatein.jcr.config.type}/config.xml
# JCR Locks configuration
gatein.jcr.lock.cache.config=classpath:/conf/jcr/jbosscache/${gatein.jcr.config.type}/lock-config.xml
# JCR Index configuration
gatein.jcr.index.cache.config=classpath:/conf/jcr/jbosscache/cluster/indexer-config.xml
gatein.jcr.jgroups.config=classpath:/conf/jcr/jbosscache/cluster/udp-mux.xml
TODO : find and indicate the location of these files in jars. Give a link to the JGroups / JBoss Cache relevant doc
You need to indicate the cluster kernel profile to eXo Platform. This can be done by editing gatein.sh like this:
EXO_PROFILES="-Dexo.profiles=default,cluster"
For the very first startup of your JCR cluster, you should only start a single node. This node will initialise the internal JCR database and create the system workspace. Once this first node is deinitely started, you can start the other nodes.
This contraint is only for the very first start. Once the initialization has been done, you can start odes in any order
Nodes of the cluster will automatically try to join others at startup. Once they discover each other, they will synchronize their state. During the synchronization the node is not ready to serve requests.
How does an admin validate that teh cluster works properly ? Is there something noticeable on screen ?
If you intend to migrate your production system from local (non cluster) mode to cluster, follow these steps :
Update the configuration to cluster mode as explained above on your main server
Use the same configuration on other cluster nodes
Move the index and value storage to the shared file system
Start the cluster