Version 6.1 of OLAT introduces support for clustering: you can now run OLAT on multiple interconnected application servers. This chapter provides details about clustered OLAT and how to set it up. Version 6.0 of OLAT already introduced the possibility of running a separate tomcat instance for handling the search index and serve search requests. The OLAT cluster in 6.1 goes further and allows having any number of tomcat instances running OLAT being combined in one OLAT cluster. This allows you to scale OLAT to the growing number of users by simply adding another OLAT node.

When setting up a cluster there are two important point of views to consider: the external and the internal. The external view describes how the system is reached from the outside and how load is distributed to the different OLAT nodes. The internal view describes how the OLAT nodes interact and what means they require for this communication.

On the external view: An important part of clustering OLAT is to define how user sessions and requests are routed to the available OLAT instances. There are different possibilities for doing this out there. The basic requirement to any solution though is to have sticky sessions, i.e. once a new user's session is routed to a particular OLAT instance, subsequent requests of the same user session must be routed to the same OLAT instance. Other than that you can use hardware loadbalances or software loadbalancers (such as Apache with mod_jk) as long as they support sticky sessions. This chapter assumes using mod_jk - but this is purely a deployment choice.

On the internal view, this change in architecture requires new forms of communication between the different OLAT nodes in order to synchronize certain actions and data. For this communication OLAT uses JMS (ActiveMQ) and the database. It is therefore important to note that all OLAT nodes in a cluster need access to the same JMS broker, the same database and the same filesystem.

Topics not covered in OLAT Clustering

Clustering in OLAT focuses on being able to increase the number of concurrent session and hence scale the number of sessions and requests. It does does not focus on High-Availability nor Session Replication