If high availability (failover) is required you can configure multiple Management Console instances to work together as a cluster. Four components must be clustered to achieve full failover.
|Load balancer||An HTTP load balancer is required to distribute requests between multiple Tomcat servers.|
|Clustered platform database||The Management Console stores schedules, robots etc. in the platform database. In a failover scenario the platform database should run on a clustered DBMS to avoid a single point of failure.|
|Tomcat session replication||
Although the Management Console doesn't store any data directly in the user's session (except during Import/Export), the session holds the user's authentication information.
If session replication is not enabled, the user will have to login again if the Tomcat he is currently connected to crashes.
Hazelcast (www.hazelcast.com) is used to cluster data structures over multiple JVMs. Inside the Management Console this is used to provide clustering of vital data structures, and to provide intercommunication between application instances.
Here is a example: When you run a robot on RoboServer, a thread is required to process the status messages returned by RoboServer. This thread will be running inside a concrete Tomcat instance. In a clustered environment, a user trying to stop the robot may in fact be generating the stop request on another Tomcat instance than the instance running the robot. In that case the stop request is broadcast through Hazelcast to all instances and the instance running the robot will receive it and act to stop the robot.
You should have 2 or more identical Tomcat installations, and
deploy the same version of
on them all. Make sure the
roles.xml files are the same across all the